GNOME Bugzilla – Bug 346742
Buffer overrun in XCF parsing code
Last modified: 2008-01-15 13:09:11 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
The same bug appears in the current CVS head.
Created attachment 68457 [details] [review]
Patch to fix. Checked to apply to 2.2.11 even though the filenames say 2.2.6.
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 <email@example.com>
* 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).
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.
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.