Summary: | media-libs/jpeg: maxmem feature not used (DoS via memory exhaustion) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Tavis Ormandy (RETIRED) <taviso> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bsd+disabled, graphics+disabled, oudomphe, tcort |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | A3? [glsa] | ||
Package list: | Runtime testing required: | --- | |
Attachments: |
Description
Tavis Ormandy (RETIRED)
2006-04-22 14:22:24 UTC
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. |