Bug 218755
| Summary: | CVE-2007-0010 GdbPixbufLoader fails to handle invalid input from Evolution correctly | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Arjan van de Ven <arjan> | ||||||||
| Component: | gtk2 | Assignee: | Matthias Clasen <mclasen> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | 6 | CC: | security-response-team | ||||||||
| Target Milestone: | --- | Keywords: | Security | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | impact=moderate,source=vendor-sec,reported=20061207 | ||||||||||
| Fixed In Version: | 2.10.4-7.fc6 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2006-12-24 15:07:10 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 218931, 218932, 219055 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Arjan van de Ven
2006-12-07 11:07:21 UTC
Created attachment 143043 [details]
mbox with the crashing mail
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. Created attachment 143153 [details]
Backtrace from FC6
evolution-2.8.2.1-2.fc6
gtk2-2.10.4-6.fc6
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. 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. Created attachment 143235 [details]
close-loader.patch
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) Possibly, but lets discuss that upstream. 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. (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. |