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:
values arent verified very well, so setting illegal values can cause crazy behaviour, for example:
# max_value can't be > 255 in a P6 (raw) ppm, this is illegal.
# however, this will kill xli
# will SIGFPE xli
# this causes odd behaviour in xli and xloadimage, and calls malloc(0)
# allocating huge amounts of memory seems to cause some sort of race
# condition in xli.
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:
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()
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.
$ touch ';id 1>&2;: .Z'
$ xli ';id 1>&2;: .Z'
gunzip: compressed data not read from a terminal. Use -f to force
For help, type: gunzip -h
;id 1>&2;: .Z: unknown or unsupported image type
This also seems to affect xloadimage.
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:
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
Stable on ppc.
all set on ia64
xloadimage stable on mips.
Already stable on hppa.