Bugzilla Bug 108365

From a Bugtraq mail by Ariel Berkman :

==============================
While creating a stripped down version of xloadimage, I have discovered
three buffer overflows in xloadimage when handling the image title name.

Unlike most of the supported image formats in xloadimage, the NIFF image
format can store a title name of arbitrary length as part of the image file.

When xloadimage is processing a loaded image, it is creating a new Image
object and then writing the processed image to it. At that point, it will
also copy the title from the old image to the newly created image.

The 'zoom', 'reduce', and 'rotate' functions are using a fixed length buffer
to construct the new title name when an image processing is done. Since the
title name in a NIFF format is of varying length, and there are insufficient
buffer size validations, the buffer can be overflowed.

A malicious user can construct a NIFF file that when viewed and processed
(with either zoom, reduce or rotate) by xloadimage, will cause the program
to overwrite the return address and execute arbitrary code.

Proof of concept for the 'zoom' image processing bug, tested on a x86
computer running Gentoo Linux:

emerge xloadimage
xloadimage -zoom 20 small.niff			(small.niff is attached)

This will execute '/bin/sh'.

Note: some systems may have the (/proc/sys/kernel/)randomize_va_space option
enabled, which will cause the program to crash instead of executing /bin/sh
in most cases. Using a larger NIFF file (large.niff.gz [800KB unzipped]), it
is possible to execute arbitrary code even when the random address space
option is enabled (with about 33% success rate).

The 'reduce' and 'rotate' bugs are similar, but require a slightly different
NIFF file and different ( processing options.

The bugs are in :

zoom.c, zoom() writes an arbitrarily large buffer into a 8192 bytes sized
buffer buf[].

reduce.c, reduce() writes an arbitrarily large buffer into a 8192 bytes
sized buffer buf[].

rotate.c, rotate() writes an arbitrarily large buffer into a 8192 bytes
sized buffer buf[].

The bugs discussed above exist in the latest xloadimage package that Gentoo
provides (xloadimage.4.1-r3), and the latest xloadimage source package from
debian I could find (xloadimage_4.1-14.2). I haven't tested xloadimage
packages from other sources.
=========================

Auditors: looks real, please doublecheck...

> zoom.c, zoom() writes an arbitrarily large buffer into a 8192 bytes sized
buffer buf[].

confirmed, just needs s/sprintf/snprintf/

> reduce.c, reduce() writes an arbitrarily large buffer into a 8192 bytes
sized buffer buf[].

confirmed, same again.

> rotate.c, rotate() writes an arbitrarily large buffer into a 8192 bytes
sized buffer buf[].

yup.

note that these attacks requires the user to process (ie zoom, reduce) the image 
with xloadimage, just viewing it is not enough.

desktop-misc: please patch

This is CAN-2005-3178

According to DSA 859-1 media-gfx/xli is affected, too. 

xli does not support niff iages, however the same code is in there and is 
exploitable via xpm images. the fix is the same, -sprintf +snprintf

Patchers/desktop please apply patch. 

Created an attachment (id=70925) [details]
xli.patch

Patch for xli from solar.

Patches additional problems of format string bug in debug macro, unchecked
pathname length in path.c, and an unchecked strcat in zoom.c (forgotten in the
Debian patch ?).

Created an attachment (id=70928) [details]
security-sprintf.patch

Patch for xloadimage from Debian.

This patch is sufficient to patch what this vulnerability is about. However,
there are some other things:
- path overflow in config.c (same as xli's path.c)
- format string in debug macro in rle.c (same as xli's rlelib.c)

Setting to Auditing, as some more work is definitely needed on those packages.

Created an attachment (id=71064) [details]
xli-gentoo.patch

Fixes prototype in xli.h with FindImage()
Package built with -fbounds-checking and passes local regression testing.

ok, patch for xli is ready, some more work needed on the xloadimage patch.

Created an attachment (id=71196) [details]
xloadimage-gentoo.patch

Here's my patch for xloadimage (= patch from Debian + adaptation of solar's
patch)
Compiles ok and seems to work.

desktop-misc: please patch.

xli-1.17.0-r2 in portage thx to Taviso.
nelchael said he will handle xloadimage, let's wait for that before calling the
arch testers.

xloadimage-4.1-r4 in CVS.

Thx Nelchael, arch testers please test and mark stable...

Target KEYWORDS:
xli-1.17.0-r2 "alpha amd64 arm hppa ia64 ~mips ppc ppc-macos ppc64 sparc x86"
xloadimage-4.1-r4 "alpha amd64 arm hppa ia64 mips ppc ppc64 ppc-macos sparc x86"

xli-1.17.0-r2 and xloadimage-4.1-r4 stable on ppc-macos

Stable on alpha.

sparc stable.

Marked both stable. thanks

amd64 happy

x86 done

Stable on ppc and hppa.

Stable on ia64.

GLSA 200510-26  
 
mips don't forget to mark stable to benifit from the GLSA. 

Stable on mips.