Bugzilla Bug 61619

there are at least 5 exploitable buffer and heap overflows in the image
handling
code. this allows someone to craft a malicious image, trick a user into viewing
the file in xv, and upon viewing that image execute arbitrary code under
privileges of the user viewing image. note the AT LEAST part of the above
sentence. there is such a plethora of bad code that I just stopped reading
after a while. there are at least 100 calls to sprintf() and strcpy() with no
regards for bounds of buffers. 95% of these deal with program arguments or
filenames, so they are of no interest to exploit. however I just got sick of
reading this code after not too long. so im sure there are still other
overflows in the image handling code for other image types.


Sounds like it would be better to hard mask xv in general...

The poster <infamous41md hotpop com> has previously filed bogus advisories. But
we'll keep it here for reference for now.

It was brought to my attention through the biggest german IT related
newsticker: http://www.heise.de/newsticker/meldung/50350 Would be news, if they
hoaxed their readers. :-/

This is confirmed by condordes. No known fix available.

I agree with Carsten, I think we should hard mask, unless upstream comes
through with a patch.

The first vulnerability in the email could lead to arbitrary code execution. 
The others would probably only cause a crash (if that), at least on Linux.

If upstream doesn't come through (given the email to Bugtraq, it sounds like he
might not), we would have to roll our own patch, and I don't know if it's worth
the effort.  I don't think very many people use xv anymore.

I suggest hard masking if no fix is found.

CC'ing usata.

waah! please don't do that, I rely on xv and use it constantly.

I'll fix the bugs, they dont seem too complex, just need to add some simple validation in there.

here's one for the bug the exploit is for:

--- xv-3.10a/xvbmp.c    2004-08-31 23:26:20.711591624 +0100
+++ xv-3.10a.new/xvbmp.c        2004-08-31 23:21:48.887915104 +0100
@@ -165,6 +165,11 @@
     int i, cmaplen;
 
     cmaplen = (biClrUsed) ? biClrUsed : 1 << biBitCount;
+
+       /* sanity check user supplied value */
+       if (cmaplen > 256)
+               { bmpError(bname,"invalid colormap length"); goto ERROR; }
+
     for (i=0; i<cmaplen; i++) {
       pinfo->b[i] = getc(fp);
       pinfo->g[i] = getc(fp);

I promise I'm working on the other ones, don't hard mask it! :)

Created an attachment (id=38628) [details]
fix security issues reported

Okay, I've checked the reported issues, I check for over and underflow, and
check the user value is sane according to the bitmap specs.

I can't find any iris image files to test with (it looks okay though), but pcx
and bmp both work.

carlo -- your thoughts?  Is this patch good enough?

Kurt, I'm really only the reporter. I don't even use xv. It's your call as the
security herd to decide, if Tavis patches suffice or if upstream
unresponsiveness indicates, that it is better to mask the package. Don't know
what's your policy in such cases.

I vote for masking unless someone (taviso ?) takes over package maintenance
with proper metadata.xml information.

But I think xv is widely used so doing so will probably do BS damage.

As for the patch correctness, our experts (solar, plasmaroo, ChrisWhite) should
have a look and give their opinion.

I'll maintain if necessary, It's definitely widely used, especially in things
like ~/.mailcaps.

I'll help test it, I use xv fairly regularly too.

taviso: please proceed in taking over that package and submitting a fixed
ebuild revision

lisa: when the ebuild will be in portage we'll call you to help test it :)

Created an attachment (id=38759) [details]
Suse's security patch

Attached the patch from Suse's "fixed" rpm package.  Gotten from
http://www.suse.de/cgi-bin/print_page_www.pl?NPSPath=/webredesign/htdocs/en/private/download/updates/91_i386.html


Havn't tested them, but it may help.

Okay, i've added suse's patch, i tested it with the supplied exploit and it
prevents it from working (mine did as well, but they look like they have more
clue about what they're doing:)

I've committed -r7 and removed previous vulnerable versions.

added metadata.xml with me as maintainer.

Already stable.. Go GLSA go

taviso congrats with the new baby;-)

GLSA 200409-07