|
|
Subscribe / Log in / New account

Banner ads: worse than you thought

Banner ads: worse than you thought

Posted Sep 8, 2005 21:14 UTC (Thu) by anton (subscriber, #25547)
Parent article: Banner ads: worse than you thought

>detecting all exploits would be a challenge

Shouldn't it be enough to check whether the image conforms to the spec
of the image format? I would expect that conforming images typically
cannot cause a buffer overflow.


to post comments

Banner ads: worse than you thought

Posted Sep 9, 2005 10:36 UTC (Fri) by ringerc (subscriber, #3071) [Link]

No.

It's entirely possible for a bug in an image loading library to expose a security hole, or a non-exploitable crash bug, that can be triggered with an unusual but standards compliant image.

Image formats are often complex things. All it takes is one buffer you copy to without checking the input length; one field you assume is in the image that isn't, or pretty much any other significant assumption about the format. The faulty code often works just fine, because no current image editing software generates images in a way that'd trigger the bug - but that doesn't mean a hand-crafted standards compliant image can't.

The situation is made worse by various extensions to the standard that must be ignored or handled. You can't just say "nope, not loading that" when 60% of the images on the 'net have a given fault, for example. Some standards are themselves sufficiently loose and complex that implementing support for the whole standard would be a mammoth and near-impossible effort. TIFF comes to mind here.

One thing I expect would help - and I hope is already being done - is to run the common image loading libraries through torture tests that feed them random strings of garbage, randomly corrupted images, etc, and save a core plus the input data whenever it crashes. Mere standards compliance is unlikely to cut it.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds