After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 346742 - Buffer overrun in XCF parsing code
Buffer overrun in XCF parsing code
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: General
2.2.x
Other All
: Normal major
: 2.2
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2006-07-06 10:36 UTC by Henning Makholm
Modified: 2008-01-15 13:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to fix. Checked to apply to 2.2.11 even though the filenames say 2.2.6. (729 bytes, patch)
2006-07-06 10:39 UTC, Henning Makholm
committed Details | Review
A simple test case (1.62 KB, application/x-xcf)
2006-07-13 10:33 UTC, Henning Makholm
  Details

Description Henning Makholm 2006-07-06 10:36:56 UTC
The problem is in the function xcf_load_vector() in app/xcf/xcf-load.c
of the source tree. For each "stroke" being read, the code reads an
uint32 from the XCF file into the variable num_axes, and then for each
control proint of the stroke reads num_axes floats from the file into
the stack-allocated array coords whose size is hard-coded as 6.

A malicious XCF file creater could write a large number into the
num_axes position and trick the XCF reader into overwriting part of
the stack with raw data read from the file. On little-endian systems,
the function xcf_read_float() that actually reads the floats does a
byte-order conversion on the data it reads but does not do any special
float processing, so an attacker has direct control of the data
written to the stack.

I have not attempted to construct an working exploit (though I did
verify being able to crash Gimp with a naively patched image file),
but there seems to be no reason why the overrun could not be used to
mount a standard arbitrary code execution attack if one can get the
victim to try to load an appropriately crafted image file.

The attack is in the VECTORS property of an XCF file which pure XCF
_viewers_ (e.g. imagemagick or xcftools) normally skip without
parsing.  Thus an attack file can easily be written such that the
image will display correctly with no symptoms at all in a viewer
application.

The same bug appears in the current CVS head.
Comment 1 Henning Makholm 2006-07-06 10:39:02 UTC
Created attachment 68457 [details] [review]
Patch to fix. Checked to apply to 2.2.11 even though the filenames say 2.2.6.
Comment 2 Sven Neumann 2006-07-06 12:44:58 UTC
Thanks a lot. I have applied the patch to both branches and will consider doing a 2.2.12 release sometime soon.

2006-07-06  Sven Neumann  <sven@gimp.org>

	* app/xcf/xcf-load.c (xcf_load_vector): applied a patch from
	Henning Makholm that introduces a sanity check on the number of
	axes (bug #346742).
Comment 3 Henning Makholm 2006-07-07 10:10:45 UTC
Micah Anderson of the Debian security team writes that he has requested and got asigned the CVE ID "CVE-2006-3404" for this bug. It is too late now to mention this tag in the 2.2.12 news file, but I mention it here so it can be found when searching the bug database.

Reference: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377049;msg=16>
Comment 4 Henning Makholm 2006-07-13 10:33:13 UTC
Created attachment 68854 [details]
A simple test case

For reference, and because RedHat asked nicely, here is a simple test case.

It will attempt to overwrite the return address on the stack with 0xDEADBEEF. Since it doesn't know the precise layout of the stack frame in the binary that's loading it, it has to contain a lot of 0xDEADBEEFs and will probably clobber a number of internal counters in the loader routine. Therefor the loader will crash before it gets a chance to attempt returning to the bogus address, but at least one can see from a core dump that the return address does get overwritten.