130889 – media-libs/jpeg: maxmem feature not used (DoS via memory exhaustion)

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.