Bug 554371
| Summary: | libtiff 3.9.x crashes if wrong data type supplied for codec-local tag | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tim Waugh <twaugh> | ||||
| Component: | libtiff | Assignee: | Tom Lane <tgl> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 14 | CC: | bressers, dakingun, hhorak, tgl | ||||
| Target Milestone: | --- | Keywords: | Security | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | abrt_hash:55a0d4c67dd9bbf1daeff6cf2b1510b48c8d7688 | ||||||
| Fixed In Version: | libtiff-3.9.4-1.fc14 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-05-24 21:39:48 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: | 589034, 611886 | ||||||
| Attachments: |
|
||||||
|
Description
Tim Waugh
2010-01-11 14:53:22 UTC
Created attachment 382991 [details]
File: backtrace
Looks like it might have security implications... This can be reproduced by running the tiffinfo command over that file. I'm moving this bug to the libtiff component. The testcase doesn't crash libtiff on RHEL5. I wonder if upstream missed a fix. This appears to be a crash only. libtiff is calling: _TIFFsetString(&sp->faxdcs, va_arg(ap, char*)); But the arg ap is a integer, so it gets confused and we end up with a bad char* pointer. I'm happy to call this not security. Tom any thoughts? Thanks. It's hard to see how it could fail to crash. The root of the problem seems to be that the file contains a LONG (ie, integral) value for tag 34911 (FAXDCS) while the library is expecting a string. There is code in TIFFReadDirectory that checks for a type mismatch, but *it only works for tag numbers that are known to the core libtiff code*. In this case the tag is a codec-specific one, so it can't be checked by the core code, and the API for codecs appears to be misdesigned so that it's impossible for the codec to protect itself against this :-(. I think we're going to have to punt this one upstream; it's not apparent to me what a reasonable fix would look like. I dunno about calling it not-security. It certainly looks like crashing the library is trivial; I'm not sure whether there is scope for anything nastier. OTOH libtiff has a sufficiently bad track record that I hope nobody is using it in security-vulnerable situations anyway :-( Filed upstream at http://bugzilla.maptools.org/show_bug.cgi?id=2210 libtiff-3.9.4-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/libtiff-3.9.4-1.fc12 libtiff-3.8.2-15.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/libtiff-3.8.2-15.fc11 libtiff-3.9.4-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/libtiff-3.9.4-1.fc13 libtiff-3.8.2-15.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. libtiff-3.9.4-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. libtiff-3.9.4-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |