#8642 closed enhancement (fixed)
gdk-pixbuf-2.36.1
| Reported by: | Douglas R. Reno | Owned by: | Douglas R. Reno |
|---|---|---|---|
| Priority: | high | Milestone: | 8.0 |
| Component: | BOOK | Version: | SVN |
| Severity: | normal | Keywords: | |
| Cc: |
Description
New point version. I'm inclined to believe that there are security issues fixed, as I can't access the bug report for
"* Fix integer overflows in the jpeg loader (#775218)"
Without a special account with special privileges. That tells me that this issue is embargoed and needs to be addressed immediately. I'm marking as High.
2.36.1 ====== * Remove the pixdata loader (#776004) * Fix integer overflows in the jpeg loader (#775218) * Add an external thumbnailer for images * Translation updates
Change History (5)
comment:1 by , 8 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:2 by , 8 years ago
| Priority: | normal → high |
|---|
comment:3 by , 8 years ago
Yes, it's exploitable. Basically, what happens is that gdk-pixbuf used to read the offset for the edge of the image's resolution directly and add it to a variable (temp), "i". Specifically crafted images (of which I downloaded one to test), will clobber certain locations in memory due to the final sum of the value. The change is to replace the offset with "2", which is the theoretical max that this will happen in.
This is based on EXIF metadata, so one could theoretically use this as an attack vector just by modifying the metadata of a JPG file. There was a test added to this version of gdk-pixbuf to test against this in its test suite.
I'm going to take a few hours to research the implications of said Integer Overflow. Meanwhile, turning it over to high.