Reported on Vendor-Sec and seems to apply to us as well: Miloslav Trmac discovered that our (and others) fixes for CAN-2003-0848 were insufficient. This needs a new CVE name for anyone vulnerable, use CAN-2005-0395, let us know if you're affected and we can co-ordinate. Thanks, Mark ---------- Forwarded message ---------- Hello, The CAN-2003-0848 heap overflow[1] was never really fixed in our (nor upstream) packages. Instead, slocate-2.6-can-2003-0848.patch was added, which drops the SGID privilege before processing databases not owned by group slocate. Unfortunately slocate does not drop privileges before _creating_ databases: slocate -U /path -o database creates a "database" file owned by $attacker:slocate. Thus the attacker can overwrite the file with needed data, exploit CAN-2003-0848 and gain slocate group privileges. Gaining slocate group privileges allows the attacker to read the complete slocate database and discover names of files belonging to other users. At least (in our) default setup this cannot be used to overwrite the "main" slocate database (and gain other user's privileges), but the code is risky at least: The attacker with group slocate cannot create files in /var/lib/slocate, nor overwrite /var/lib/slocate/slocate.db directly, but updatedb first creates /var/lib/slocate/slocate.db.tmp using fopen (..., "w"); so _if_ root runs updatedb with umask 002 or 000, the file is writable by group slocate. Therefore the attacker can obtain a writable file descriptor to slocate.db.tmp while updatedb is running, wait after updatedb finishes (and renames the file to slocate.db), and write the exploit payload to the database. This is mitigated (aside from the above-mentioned need to run slocate with non-default umask) by the fact that slocate changes the mode of slocate.db.tmp to 0640 after writing the first data entry to the file; this makes the window when slocate.db.tmp can be opened for writing by the attacker much smaller, but probably still possible to hit. A suggested fix is attached; it drops the SGID slocate privilege before creating a database when not run as root. Actually fixing the heap overflow this time also seems like a good idea. I have not notified anybody other yet; from a quick look around: - the upstream sources are still vulnerable to the original heap overflow, with no attempt to fix it - Debian slocate-2.7-4 drops SGID privileges before creating any database (regardless of invoking user) - Mandrake slocate-2.7-4mdk has the same problem as RH's packages Mirek [1] http://marc.theaimsgroup.com/?l=bugtraq&m=106546447321274&w=2 if (pathlen < 0) { ...fatal error... } ... *(...heap-allocated array... + (pathlen-1)) = ...user input... does not protect against pathlen == 0 --- slocate-2.7.orig/main.c 2005-02-25 01:27:05.000000000 +0100 +++ slocate-2.7/main.c 2005-02-25 01:58:57.579083312 +0100 @@ -966,8 +966,15 @@ int i; char **dirchk; - if (!NEWOUTPUT && UID != SLOC_UID) { - report_error(FATAL,QUIET,"%s: You are not authorized to create a default slocate database!\n",progname); + if (UID != SLOC_UID) { + if (!NEWOUTPUT) { + report_error(FATAL,QUIET,"%s: You are not authorized to create a default slocate database!\n",progname); + } + + if (getegid () == SLOC_GID) { + if (setgid(GID) == -1) + report_error(FATAL, QUIET, "%s: Could not drop privileges.", progname); + } } fd = fopen(TMPSLOCATEDB,"w");
More info: The heap overflow was in fact fixed in upstream slocate-2.7 (without being mentioned in the changelog). Thus, unless there is a different bug in the database reading code, this cannot be used to gain group slocate. This does not change the fact that the "slocate-2.6-can-2003-0848.patch" alone does not actually fix CAN-2003-0848. Sorry for the alarm, Mirek [1] The change in slocate-2.7 fixing the overflow is --- slocate-2.6/main.c 2001-05-22 07:34:35.000000000 +0200 +++ slocate-2.7/main.c 2003-01-25 05:39:48.000000000 +0100 @@ -1239,10 +1246,19 @@ } else if (code_num > 127) code_num = code_num - 256; - code_ptr += code_num; + /* FIXME sometimes pathlen is < 0 but it shouldn't be. + * corrupt database file? + * This could be from a bug in frcode() or decode_db(). I + * am leaning toward frcode() at the moment */ + code_ptr += code_num; pathlen = code_ptr - codedpath; - + + if (pathlen < 0) { + fprintf(stderr,"%s: decode_db() aborted. Corrupt database?\n",progname); + exit(1); + } + jump = 0; while (!jump) { ch = *begin_ptr;
does this really apply to us considering we havent had slocate-2.6 in our tree for almost 2 years now ?
I think we can consider we are not affected, since 2.6 in unavailable. It wasn't a big deal of a bug anyway. Reopen if you disagree.
