Bug 218755 - CVE-2007-0010 GdbPixbufLoader fails to handle invalid input from Evolution correctly
CVE-2007-0010 GdbPixbufLoader fails to handle invalid input from Evolution co...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gtk2 (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthias Clasen
impact=moderate,source=vendor-sec,rep...
: Security
Depends On:
Blocks: 218931 218932 219055
  Show dependency treegraph
 
Reported: 2006-12-07 06:07 EST by Arjan van de Ven
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.10.4-7.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-24 10:07:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
mbox with the crashing mail (49.40 KB, application/octet-stream)
2006-12-07 06:07 EST, Arjan van de Ven
no flags Details
Backtrace from FC6 (2.71 KB, text/plain)
2006-12-08 10:18 EST, Lubomir Kundrak
no flags Details
close-loader.patch (1.69 KB, patch)
2006-12-09 23:12 EST, Matthias Clasen
no flags Details | Diff

  None (edit)
Description Arjan van de Ven 2006-12-07 06:07:21 EST
Description of problem:


evolution crashes on the spam mail I'll attach as mbox; the crash may well turn
out to be a security issue in itself. But just crashing is serious since the
next time evo opens it immediately goes back to the same mail and crashes again,
so a non-expert user cannot recover from this.

I suspect RHEL5 is affected too
Comment 1 Arjan van de Ven 2006-12-07 06:07:21 EST
Created attachment 143043 [details]
mbox with the crashing mail
Comment 2 Lubomir Kundrak 2006-12-08 10:08:47 EST
The file "navigable.gif" is incorrectly encoded. I think evolution should not
feed underlying gdk with the corrupted data, but I doubt an assertion failure
there is the right way to handle the faulty gif.

When you extract the file (with reformime or evolution) and either try to view
it with firefox or gqview or embed it in another email message and open in
evolution it is correctly reported as being broken.

Moreover there's some interesting stuff in the broken base64 data: for example
the IN-SB-8XX-PLATFORMS string encoded there. How could it happen to came there?
Maybe this message was meant to exploit some windows software or encoded by a
horribly broken software? I got no smarter after disassembling the 8bit parts of
the part.
Comment 3 Lubomir Kundrak 2006-12-08 10:18:27 EST
Created attachment 143153 [details]
Backtrace from FC6

evolution-2.8.2.1-2.fc6
gtk2-2.10.4-6.fc6
Comment 4 Matthias Clasen 2006-12-08 11:10:59 EST
Looks like memory corruption to me. 
I don't see how that assert can trigger, unless something scribbles over the
pixbuf, since all pixbuf_new calls in the gif loader create pixbufs with alpha.
Comment 5 Matthias Clasen 2006-12-09 23:12:09 EST
I found that gtkhtml ignores the return value of gdk_pixbuf_loader_write() and
just continues throwing invalid data at the loader.
Admittedly, the GdkPixbufLoader documentation makes it sound as if that was ok, 
since it says that the loader is closed if write() returns FALSE. This is not 
actually the case right now. I'll attach a patch which changes gdk-pixbuf to 
behave as documented. This fixes the bug.

Comment 6 Matthias Clasen 2006-12-09 23:12:55 EST
Created attachment 143235 [details]
close-loader.patch
Comment 7 Arjan van de Ven 2006-12-10 13:01:44 EST
should gdk_pixbuf_loader_write() be marked for warning on unused results? 
(the gcc feature that causes it to warn if you don't actually use the result of
a function)
Comment 8 Matthias Clasen 2006-12-24 10:07:10 EST
Possibly, but lets discuss that upstream.
Comment 9 Arjan van de Ven 2007-01-08 14:24:53 EST
interesting that Red Hat considers this "EMBARGOED"; I consider it very public 
already; the mail that exposed the bug is already distributed outside embargo 
anyway.

I would suggest that RH removes the embargoed status of this bug.
Comment 10 Lubomir Kundrak 2007-01-10 05:04:36 EST
(In reply to comment #9)
> interesting that Red Hat considers this "EMBARGOED"; I consider it very public 
> already; the mail that exposed the bug is already distributed outside embargo 
> anyway.
> 
> I would suggest that RH removes the embargoed status of this bug.

Okay, I am removing the Security sensitive flag, and EMBARGO, as you wish.
I thought it should be embargoed because it was reported via private
vendor-sec mailing list, and the bug was flagged Security sensitive.

Note You need to log in before you can comment on or make changes to this bug.