Bugzilla Bug 79762

xli and xloadimage use insufficient validation when parsing images, there is
almost certainly a security issue waiting to be found in there somewhere that
could be exploited by getting a user to display an image with one of these
utilities (via gpg key photos, for example).

examples of insufficient validation:

ppm images are simple pixmap files, you can read about the format here:

http://netpbm.sourceforge.net/doc/ppm.html

values arent verified very well, so setting illegal values can cause crazy
behaviour, for example:

P6
1 1
# max_value can't be > 255 in a P6 (raw) ppm, this is illegal.
# however, this will kill xli
256
FOOBAR

P3
1 1
# will SIGFPE xli
0e1
FOOBAR

P3
# this causes odd behaviour in xli and xloadimage, and calls malloc(0)
0 0
1
FOOBAR

P3
# allocating huge amounts of memory seems to cause some sort of race 
# condition in xli.
9999 9999
1
FOOBAR

I've also noticed return codes from libpng are sometimes ignored, I'm not sure
if that's such a good idea, it will happily try to display illegal png files,
I've seen it segfault after this, although i no longer have the png file that
caused it or a core file...if it happens again i'll try to track it down.

Look at these two examples I just tried:

P3
1073741825 4
16
FOOBAR

P3
65536 65536
16
FOOBAR

both overflow the value passed to malloc, and then die trying to copy the image data past the allocated buffer. I'm confident this could lead to an attack, I've emailed the author for his opinion.

xli suffers from a bug fixed in xloadimage in 2001:

details here: http://archives.neohapsis.com/archives/bugtraq/2001-07/0160.html

rob@leet ~/projects/test/xli-1.17.0 $ xli ./foo.faces 
./foo.faces is a  32x32 8-bit grayscale Faces Project image
xli: stack smashing attack in function facesLoad()
Aborted

There's also a quoting problem in xli's zio.c

sprintf(buf, "gunzip -c %s", name);

If a user were to use xli via ~/.mailcap or similar, someone could send a file with Content-Type set to image/jpeg and a filename like ';id 1>&2;: .Z', they could potentially execute arbitrary shell commands.

example:

$ touch ';id 1>&2;: .Z'
$ xli ';id 1>&2;: .Z'
gunzip: compressed data not read from a terminal. Use -f to force
decompression.
For help, type: gunzip -h
uid=1000(taviso) gid=100(users)
groups=5(tty),10(wheel),16(cron),19(cdrom),35(games),100(users),250(portage)
;id 1>&2;: .Z: unknown or unsupported image type

This also seems to affect xloadimage.

upstreamn informed.

any news yet?

CC'ing desktop-misc herd for xloadimage, xli is no-herd

xli author responded that he's planning a new release to fix these two issues
by next week.

A new upstream version is available that fixes these problems:

http://pantransit.reptiles.org/prog/xli/xli-2005-02-27.tar.gz

This is somewhat noherd, we've got lu_zero (from graphics herd) approval to fix
them.

xli-1.17.0-r1 contains the fixes

Waiting for xloadimage to get backported fix too...

media-gfx/xloadimage-4.1-r2 contains the shell meta-char escaping from xli.

Arches, please test and mark stable :
media-gfx/xli-1.17.0-r1: x86 ppc hppa
media-gfx/xloadimage-4.1-r2: alpha amd64 arm hppa ia64 mips ppc ppc64 sparc x86 ppc-macos

stable on ppc64

stable on amd64

x86 there

sparc stable.

Stable on ppc.

all set on ia64

Stable ppc-macos.

xloadimage stable on mips.

Alpha stable.

GLSA 200503-05

Already stable on hppa.