we're distribute the jpeg library without a feature it calls `maxmem`, which is used to restrict images from allocating ridiculous amounts of memory and allowing developers to specify a reasonable limit for allocation. The documentation all assumes this feature is enabled, and documents settings suc as the JPEGMEM environment variable, max_mem_to_use jpeg option, the -maxmemory argument to djpeg and so on. A user might reasonably expect these setttings to prevent a malicious image from disrupting any image processing routines that accept images from users, however they do nothing, potentially resulting in a dos via memory exhaustion. Suggest adding --enable-maxmem option to configure, which will solve this problem.
Created attachment 85214 [details] example image
graphics herd: please provide an updated ebuild, or comment if appropriate.
what exactly would you say a reasonable limit is ?
How about we replace jpeg_mem_init() in jmemansi.c with a routine that that uses sysconf() with _SC_PHYS_PAGES? example: GLOBAL(long) jpeg_mem_init (j_common_ptr cinfo) { long phys_size; if ((phys_size = sysconf(_SC_PHYS_PAGES)) == -1) return DEFAULT_MAX_MEM; /* defined by libjpeg via --enable-maxmem=xx */ if ((phys_size *= sysconf(_SC_PAGESIZE)) < 0) return DEFAULT_MAX_MEM; return phys_size; } and set DEFAULT_MAX_MEM to 64M or similar as a fallback? This would be a reasonable default, but allow JPEGMEM and max_memory_to_use to be honoured by users who want to prevent memory exhaustion.
Created attachment 85252 [details, diff] jpeg-sysconf-maxmem.diff suggested patch, tested with --enable-maxmem=64 (only used as a fallback)
Created attachment 85260 [details, diff] sysconf maxmem patch the comments in jmemansi.c say "If you can actually get the available space, it's a good idea to subtract a slop factor of 5% or so.", so this patch does that.
Misplaced
graphics team please patch
I had to drop ~x86-fbsd keyword from -r7 because the calls are very linux specific, I do have a portable patch, if that can be used instead of the current would be perfect.
Created attachment 87770 [details, diff] Updated patch supporting FreeBSD and DragonFly and with fallback.
arches please test and mark 6b-r7 stable, thanks
alpha stable.
Darwin has a problem similar to BSD. However, Diego's patch won't work for us. I need something like this: #if HAVE_SYSCTL && defined HW_PHYSMEM { /* This works on *bsd and darwin. */ unsigned int physmem; size_t len = sizeof physmem; static int mib[2] = { CTL_HW, HW_PHYSMEM }; if (sysctl (mib, ARRAY_SIZE (mib), &physmem, &len, NULL, 0) == 0 && len == sizeof (physmem)) return (double) physmem; } #endif Diego, is your patch yet in (doesn't look like so), and can above code be combined with yours? I grabbed above thing from http://www.opensource.apple.com/darwinsource/WWDC2004/gccfast-1614/libiberty/physmem.c I cannot mark this package stable on ppc-macos because the package doesn't compile.
sparc stable.
Created attachment 88017 [details, diff] Updated patch supporting *BSD and Darwin and with fallback. Here it is, thanks Fabian :)
Created attachment 88028 [details, diff] Re-Updated patch supporting *BSD and Darwin and with fallback. this patch fixes the return type to be long, and to return 0 in case the condition does not hold.
stable on ppc64
Comment on attachment 88028 [details, diff] Re-Updated patch supporting *BSD and Darwin and with fallback. this patch is wrong. Don't use it. Sorry for the spam.
Created attachment 88029 [details, diff] latest darwin/bsd/linux maxmem patch from SVN by Flameeyes Attached is the proper fix for BSD/Darwin and GNU/Linux. This patch should be put in the patch file after which I can mark ppc-macos stable. Taviso or who is responsible: could you add + patchrevbump this patch to the current ebuild? Thanks.
amd64 stable.
on x86: compiles fine. Further I ran several transformations on an image which also went fine and gave the expected result. I also tested the functionality of the library itself by using KDE and Gimp which worked fine as well.
ppc stable
x86 done, thanks for testing Sander
Stable on hppa
*** Bug 135644 has been marked as a duplicate of this bug. ***
Calling a GLSA vote on this one: <taviso> re jpeg, i dont think glsa is nescessary, it's very lame...just a client dos Does any important applications use this?
(In reply to comment #26) > Does any important applications use this? Many applications do. Here is a list of some popular apps that use it: emacs, wine, abiword, ghostscript-*, php, blender, gimp, gphoto2, cups, mozilla{-firefox}, qt, opera, and others. Complete List: http://gentoo-portage.com/media-libs/jpeg/RDep#ptabs
Ok lets have the GLSA.
yes, as for me a GLSA is needed, since this issue allows me to crash nearly every computer of my friends :), whatever they use (konq, firefox, safari, IE...). Some other linux distributions, and MacOS, windows... are affected too.
GLSA 200606-11 arm, bsd, ia64, mips, ppc-macos, s390, sh don't forget to mark stable to benifit from the GLSA.
Did _anybody_ take into consideration my and Grobian's messages? Both Gentoo/*BSD and Gentoo for Mac OSX are cut off by that patch unless someone apply our version, that's a no-op for anyone else. If nobody from the interested parts is going to make that change in 24h, I suppose either me or Grobian will do that, but consider that anybody wanting to scream at us afterward will have had enough time to validate and comment.
Sorry Diego I thought that it had already been applied. Taviso who applied the initial patch has been mostly away for some weeks due to a job change. (no screaming from here)
Diego, as I'll not be able to do this and mark ppc-macos today/tonight (no access to my machine), can you do this if you have time? Please also set the proper ppc-macos keyword if you do, I already tested with your patch. Thanks.
I updated the patchset to include Darwin/BSD fixes. Marked ppc-macos stable. Flameeyes can you manage the overlay (to which I committed the last cleaned up and working version of the patch) in the way you like? (e.g. removing or whatever, the patch is now in the main tree)
6b-r7 stable on mips.
