CVE-2016-9082: DOS attack in converting SVG to PNG
Bug #1639372 reported by
Jeremy Bícha
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cairo |
Unknown
|
Critical
|
|||
cairo (Debian) |
Fix Released
|
Unknown
|
|||
cairo (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Precise |
Won't Fix
|
Medium
|
Unassigned | ||
Trusty |
Confirmed
|
Medium
|
Unassigned | ||
Xenial |
Fix Released
|
Medium
|
Unassigned | ||
Yakkety |
Confirmed
|
Medium
|
Unassigned |
Bug Description
I'm attaching debdiffs for trusty, xenial and yakkety. Zesty is already fixed by syncing cairo 1.14.6-1.1 from Debian. Maybe someone else can work on the precise update.
Proof of Concept at
http://
I didn't get gdb to work, but when I tried to convert the file, I got a crash report named /var/crash/
I reproduced the crash and verified that the new package doesn't crash on yakkety. In xenial I wasn't able to reproduce the crash. I did not test on trusty.
CVE References
description: | updated |
Changed in cairo (Debian): | |
status: | Unknown → Fix Released |
Changed in cairo (Ubuntu): | |
importance: | Undecided → High |
Changed in cairo: | |
importance: | Unknown → Critical |
status: | Unknown → Confirmed |
Changed in cairo: | |
status: | Confirmed → In Progress |
Changed in cairo: | |
status: | In Progress → Unknown |
To post a comment you must log in.
This is in cairo-1.14.6
This has already been reported on oss-security, although there is no analysis there and as yet there is no CVE:
http:// www.openwall. com/lists/ oss-security/ 2016/10/ 06/1
The repro uses:
rsvg-convert -o crash.png crash.svg
The crash happens because write_png passes invalid (off by 4GByte) pointers to libpng. The bug is in the declaration of _cairo_ image_surface which obviously won't work on a machine with a 64-bit address space and 32-bit (int) values.
The crash is 'just' a read from the invalid pointer inside libpng, however there is at least one other case of the loop in read_png where the crash would be a memory overwrite with data from the PNG; that version has been semi-fixed.
I'm not posting a detailed analysis because I'm not sure how many places the bug is exposed and it is pretty clear given the fact that the loop in read_png is different that you already know about one instance of this bug.
The libpng maintainer has a copy of my complete analysis and the original SVG, I suggest not posting it at the moment because it took me about 4 minutes to find the problem given the SVG.
I also suspect it isn't specific to SVG; I assume the read_png change came from test jockeys hitting Cairo with various obvious PNG files, they tend to not test SVG anywhere near as much.
The fix is to change 'stride' in the surface to (size_t), and preferably width/height to (uint32_t) and depth to (unsigned). Doing that will reveal all cases of the bug given a sufficiently high warning level.