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.
