Your message dated Mon, 11 Aug 2008 19:28:18 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Closing old security bug with versioning
has caused the Debian Bug report #377049,
regarding gimp: Buffer overrun in XCF reading code
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
377049: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377049
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: gimp
Version: 2.2.6-1
Severity: grave
Tags: security patch
Justification: user security hole
I have reported this bug privately to the maintainer and the security
team, but it turns out that the upstream developers have no way of
reporting security bugs privately, so it is hereby in the open. It
is #346742 in the upstream bug tracking system.
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 unstable (2.2.11) and experimental (2.3.9)
versions, as well as the upsteam CVS head.
The attached patch should fix it (more gracefully than the one in my
earlier private report).
diff -rU6 gimp-2.2.6/app/xcf/xcf-load.c gimp-2.2.6.new/app/xcf/xcf-load.c
--- gimp-2.2.6/app/xcf/xcf-load.c 2004-11-03 12:50:37.000000000 +0100
+++ gimp-2.2.6.new/app/xcf/xcf-load.c 2006-07-06 12:27:33.982404488 +0200
@@ -1658,12 +1658,18 @@
xcf_seek_pos (info,
info->cp + 4 * num_axes * num_control_points,
NULL);
continue;
}
+ if (num_axes < 2 || num_axes > 6)
+ {
+ g_printerr ("bad number of axes in stroke description\n");
+ return FALSE;
+ }
+
control_points = g_value_array_new (num_control_points);
anchor.selected = FALSE;
for (j = 0; j < num_control_points; j++)
{
--- End Message ---
--- Begin Message ---
Version: 2.2.12-1
--- End Message ---
