An integer overflow, leading to heap-based buffer overflow was found in the way portable pixmap format (PPM) image file format handler of GEGL, a graph based image processing framework, processed certain input PPM image file headers. A remote attacker could provide a specially-crafted PPM image that when opened in gegl executable would lead to crash, or, potentially arbitrary code execution with the privileges of the user running the binary. This issue was found by Murray McAllister, Red Hat Security Response Team.
This issue affects the version of the gegl package, as shipped with Red Hat Enterprise Linux 6. -- This issue affects the versions of the gegl package, as shipped with Fedora release of 16 and 17.
This issue has been assigned CVE-2012-4433
Looked at other places in the code, some of the multiplications going on there seems to be un-safe, but cant find a way to trigger an overflow yet. For example in png-load.c: pixels = g_malloc0 (width*bpp); Here width = gint (4 bytes on x86-32) and g_malloc0's argument is gsize which is again 4 bytes on x86-32, so there is a potential for an overflow here. However libpng in some one seems to cap the value of width here to < 32 bits so i am not able to trigger an overflow via crafted png files. I observed similar things for jpeg and other formats gegl reads.
Created attachment 614202 [details] quick fix, implements a safemultiply function, not sure if its portable though
Created attachment 614203 [details] quick fix, implements a safemultiply function, not sure if its portable though New patch, use unsigned.
Created attachment 633906 [details] Proposed patch against gegl git master These 3 cumulative patches against git master make gegl crash with a SIGTRAP in a controlled fashion when it fails to g_malloc() about 12 Exabytes of memory. Ideally it would use g_try_malloc() to avoid a crash, but error propagation doesn't seem to work reliably in gegl -- so rather crash deterministically here than in an uncontrolled fashion somewhere else. The first patch checks values before doing potentially overflowing calculations and checks the allocated memory before using it (which is a no-op until error propagation works and g_try_malloc() is used). The second patch uses long ints as operands (to avoid overflowing memory size calculations) and checks if calls to strtol() fail or contain non-decimal values (violating the file format). The third patch corrects a comment concerning interpretation of certain file format header fields.
This is now public via: http://git.gnome.org/browse/gegl/commit/?id=1e92e5235ded0415d555aa86066b8e4041ee5a53 http://git.gnome.org/browse/gegl/commit/?id=4757cdf73d3675478d645a3ec8250ba02168a230
Created gegl tracking bugs for this issue Affects: fedora-all [bug 873182]
Acknowledgements: This issue was discovered by Murray McAllister of Red Hat Security Response Team.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2012:1455 https://rhn.redhat.com/errata/RHSA-2012-1455.html
gegl-0.2.0-11.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
gegl-0.2.0-11.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
gegl-0.2.0-11.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.