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 attachment 38628 [details, diff] 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 attachment 38759 [details, diff] 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
