I noticed what might be a securty bug in the file jmemname.c in the libjpeg library, but I'm not sure if the code ever gets called in practice (if not I assume this can be ignored), the bug lies in the following code, select_file_name (char * fname) { FILE * tfile; /* Keep generating file names till we find one that's not in use */ for (;;) { next_file_num++; /* advance counter */ sprintf(fname, TEMP_FILE_NAME, TEMP_DIRECTORY, next_file_num); if ((tfile = fopen(fname, READ_BINARY)) == NULL) { /* fopen could have failed for a reason other than the file not * being there; for example, file there but unreadable. * If <errno.h> isn't available, then we cannot test the cause. */ #ifdef ENOENT if (errno != ENOENT) continue; #endif break; } fclose(tfile); /* oops, it's there; close tfile & try again */ } There are only 999 possible temporary file names if a local user was to create these 999 files this code would appear to get stuck in an infinite loops causing a denial of service. I've tried contacting the authors of the libjpeg package but the only email address I could find for them (jpeg-info@uunet.uu.net ) bounces.
Audit team, please confirm
the files select_file_name appear in: jmemdos.c jmemname.c jpeg provides a bunch of different memory managers including the two mentioned above, but most are never used ... the configure file selects a memory manager based upon a bunch of tests and sets the internal var MEMORYMGR before creating the Makefile from makefile.cfg and replacing @MEMORYMGR@ in the process ... the only managers that configure has the choice of selecting are (in order of preference): jmemnobs.c jmemansi.c jmemname.c jmemnobs.c is always selected unless the user passes '--enable-maxmem' to the configure script (which we dont do in Gentoo) ... if maxmem is turned on, then the configure script will look for the 'tmpfile()' function in stdio.h (which always exists on Gentoo/Linux), and if *that* fails, configure will fall back to jmemname.c at which point this is an issue :) so, in order for the select_file_name() function to be built into libjpeg on Gentoo box, the user must: - change the ebuild configure proccess to pass '--enable-maxmem' - be running a libc where '#include <stdio.h>' fails to compile with tmpfile() also, the '%03d' used in the template means that it'll zero-pad the number to 3 places, not that it'll truncate to three places: $ printf "%03d\n" 9 009 $ printf "%03d\n" 99999 99999 about the only thing you could say is wrong here is that if you manage to create ~2^31 jpeg's in one process (on a 32bit host), you'll overflow the static int next_file_num
Thanks vapier for this detailed analysis ! OK, so Gentoo Linux is not affected by this problem, and furthermore it's a really convoluted way of doing a Local DoS on a machine. Resolving as WORKSFORME
