Comment 0 for bug 27952

Package: imagemagick
Version: 6:6.2.3.0-1
Severity: grave
Tags: security patch
Justification: user security hole

Specially crafted file names cause programs using ImageMagick to crash
due to a format string vulnerability. It might be possible to execute
arbitrary code due to this bug.

I've discovered the vulnerability while investigating the upstream fix
for #297990 (CAN-2005-0397). It turns out that this fix is buggy and
doesn't plug the security hole. Originally, the format string
vulnerability could be demonstrated with

convert foo.jpg foo%n.jpg # (or several %n until overflow happens)

Now all we need is one additional, valid, numeric format string, eg.

convert foo.jpg foo%d%n.jpg # (or several %n until overflow happens)

The new code just checks for the presence of any of %%, %d, %o, or %x.
If one if them is found, it passes the rest of the string as a format
string to an sprintf()-style function just like in the CAN-2005-0397
vulnerability. It all happens in SetImageInfo() that is usually called
on the target filename in write operations, eg. the target filename of a
'convert'.

I'm not sure which upstream version was the first to contain this new
incarnation of the vulnerability, but 6:6.2.3.0-1 was the first that
appeared in Debian. While sarge contains an earlier version, etch and
sid are affected. As this is really is a new vulnerability, I assume
CAN-2005-0397 should not be reused. Security team, can you please
confirm and possibly provide a new CVE ID?

I'm attaching an untested patch that should give an idea on how to plug
this hole once and for all. Note that the original fix that went into
sarge was buggy as well: The code is actually supposed to expand an
optional numeric format specifier to support multi-frame images. The
sarge security patch broke this by preventing any format string
expansion, but that's a different story.

Regards,

Daniel.