Banner ads: worse than you thought
Over the last few years, there has been a long and tiresome series of buffer overflow vulnerabilities in the libraries which interpret various image formats. Often, the associated updates are widespread, needing to update several packages which use the affected libraries. Closing these vulnerabilities may seem like a pointless exercise; we may not expect to be attacked by way of an image file. But applications like web browsers and instant messaging clients do accept images from unknown sources, and that makes them vulnerable to attack. Even some CD players will grab and display images (CD covers) from the net. If an image library is vulnerable, the software which uses that library is vulnerable, and there can be no doubt that, where a vulnerability exists, certain people will be there to exploit it.
Advertising networks look like an especially effective means for the dispersal of malicious images. Even if every company which serves advertisements were diligent in checking all images for malware (unlikely), detecting all exploits would be a challenge. Meanwhile, a widespread ad network can distribute images from no end of web sites, most of which are unlikely to be compromised in more straightforward ways. The person reporting this particular episode noted that The Onion's site was one of those distributing malicious images; The Onion may have a stranger than normal sense of humor, but it does not extend to practical jokes of this nature.
One hopes that the image-handling libraries will get more secure over
time. One may not be so naive as to hope that more complex things, such as
Flash, will also improve, but a Flash-free browser generally yields a
better web experience anyway. Meanwhile, it is well to remember that any path which
allows data into our systems may be used against us, and advertising
networks are a path with true strangers at the other end. Online ads are
obnoxious enough as it is; if they become known for carrying malware, even
more people will likely find themselves motivated to block ads altogether.
Posted Sep 1, 2005 5:55 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link] (4 responses)
Posted Sep 1, 2005 9:13 UTC (Thu)
by alonz (subscriber, #815)
[Link] (3 responses)
Posted Sep 1, 2005 14:08 UTC (Thu)
by Duncan (guest, #6647)
[Link] (2 responses)
Posted Sep 1, 2005 16:52 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link]
Posted Sep 7, 2005 11:34 UTC (Wed)
by arafel (subscriber, #18557)
[Link]
The option is "Allow websites to install software". It has a check box to the left, and a button to the right which lets you edit a list of websites which are permitted to install software. The button to the right is disabled if the box is not checked.
In my case, the list contains only addons.mozilla.org. I don't remember whether I put that there or it came that way.
Posted Sep 1, 2005 16:03 UTC (Thu)
by pflugstad (subscriber, #224)
[Link]
I just see a user posting about getting some kind of malware on his system, but no real information on how it got there. There's a long thread over on broadband reports that seems related:
<http://www.broadbandreports.com/forum/remark,14196120>>
Some people report getting it when running FF 1.0.6 on SuSE, which really makes me think this is not an image buffer overflow (a cross platform image buffer overflow would be a real piece of work). At the end, one question is whether this is coming in via an old Java hole, which might actually make more sense.
Posted Sep 1, 2005 23:10 UTC (Thu)
by cventers (guest, #31465)
[Link]
Posted Sep 4, 2005 22:15 UTC (Sun)
by dps (guest, #5725)
[Link]
Java and javascript are also invaluable for doing things like progress meters, web pages that look fetch server side data while you are using them, etc (all of which web applications are liable to need or want).
Note that in these cases the client side scripting is there to *increase* your security, provide basic functionality or both. In my experience living with the java sandbox is not a problem for these applications.
Posted Sep 8, 2005 21:14 UTC (Thu)
by anton (subscriber, #25547)
[Link] (1 responses)
Shouldn't it be enough to check whether the image conforms to the spec
Posted Sep 9, 2005 10:36 UTC (Fri)
by ringerc (subscriber, #3071)
[Link]
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.
Posted Sep 9, 2005 10:29 UTC (Fri)
by ringerc (subscriber, #3071)
[Link]
Libraries like libjpeg, libtiff, libpng and friends are loaded into a program's address space, and have read/write access to most of the program's memory. If they do something that causes memory corruption, it'll often bring the whole app down - and not generally neatly. Similarly, if a library segfaults, it's very difficult for the host app to recover from this when it's possible at all. The best most apps can hope for is to emergency save their files and crash out politely.
Given this, image libraries are a core part of the stability of a desktop. Images come in from anywhere and everywhere, with all sorts of bizarre non-compliant aspects, mangling, and corruption. Apps will be unable to detect many of these, and must rely on the image loading library doing the right thing.
As far as I know, application authors have little they can do about this, short of shoving image library use out into a separate process and doing highly inefficient IPC to it. I've not been able to find out about any way of sanely isolating a library, anyway. (This and decent reflection are the two things that make C# sound attractive compared to C++ to me).
So ... we're at the mercy of image libraries. Freetype is in a similar category - apps just have to hope it's paranoid enough. There are enough crash reports in the Scribus bug tracker that have turned out to be bad images / bad fonts to suggest that these libraries aren't there yet in terms of robustness and paranoia.
In the end, this is about more than security. It's about the ability to build apps on a solid foundation.
Posted Sep 12, 2005 17:50 UTC (Mon)
by ahz (guest, #27372)
[Link]
https://bugzilla.mozilla.org/show_bug.cgi?id=272138
Posted Sep 12, 2005 17:54 UTC (Mon)
by ahz (guest, #27372)
[Link]
Later, the project could be extended to test for non-security issues such as proprietary markup incompatible with Firefox.
http://forums.mozillazine.org/viewtopic.php?t=308463&...
The linked-to article says nothing about malware contained in an image, or buffer overflows. It says that Firefox was configured to allow websites to install software, unchecked, and the malware was in an .exe file. The user evidently thought that anti-virus software would make such a configuration safe.
Huh?
My understanding from the article is that the checkbox for "Allow web sites to install software" is unchecked--thus, web sites are not allowed to install software. You've probably misplaced the quotes in your reading...
You're reading it wrong
Likewise. The checkbox allowing software installation was unchecked, by You're reading it wrong
my parsing. Does "Allow websites to install software unchecked" even make
sense? Who in their right mind would turn ON such a thing, or for that
matter, phrase a question in that manner as a programmer?
I guess the real resolution would be to have someone running Firefox
(preferably the MSWormOS version) verify the exact wording of the option,
but it appears to me, barring evidence to the contrary, that "unchecked"
refers to the box, and shouldn't be parsed as part of the option, since
it's outside the quotes indicating the wording for the option.
Of more interest to me, however, would be the exact mechanism the thing
used to run. Note that the list post does /not/ specify whether Java and
scripting were enabled or not, nor what plugins were present and whether
they were enabled (does Firefox allow general or per-site plugin
disabling, Konqueror, my normal browser does, so I assume Firefox does as
well). All the post specifies is that it was the latest MSWormOS version
of Firefox, that eXPrivacy was updated on critical updates, and that the
allow software installation option was unchecked (plus that NAV and etc
didn't catch it).
Thus, we are left wondering what mechanism was used to actually activate
the small exe. Was it a buffer overflow in the image libraries as our LWN
article implies, or yet another exploit in Java or scripting, or possibly
some plugin (Flash or the like) exploit? The library buffer overflow
thing is the most damning possibility, as tho most modern browsers allow
image toggling, browsing the web without images by default is an idea most
folks find distasteful, even if it /does/ save them from most ads and web
beacon tracing.
OTOH, while most folks have plugins/java/scripting activated, many
security conscious folks choose not to, by default. I know I've been
running without that sort of stuff on by default since my days as an
active IE4 public beta tester, loonnggg before I seriously considered
switching to Linux, when it was just coming up on the radar for me. Of
course, since I now choose to run freedomware only, not slaveryware, I
don't even /have/ most plugins installed, including Java (yes, I'm aware
of the free implementations, but I don't have them installed), so the only
active content I /can/ run is scripting, and that's off by default, tho if
the exploit only required images and scripting, if it were to target Linux
and a site such as say /. I regularly visit, it's possible I'd be
vulnerable.
Duncan
The language is confusing. I read the word "unchecked" to mean that the software would not be checked (e.g. for a digital signature) before running it; apparently your reading is that there was a check box that was not checked.
You're reading it wrong
>I guess the real resolution would be to have someone running FirefoxYou're reading it wrong
>(preferably the MSWormOS version) verify the exact wording of the option,
>but it appears to me, barring evidence to the contrary, that "unchecked"
In reading the article, I don't see anything at all indicating that this may have happened via an image buffer overflow. Looking around for other related messages, I do see someone else posting that more and more "droppers" (which is what asdf.exe appears to be) are coming in via .png or .jpg, but I still think it's still a leap to say that that is the vector here.what's the vector?
Yet another reason to dynamically link *everything* in this day and age - Banner ads: worse than you thought
if zlib has a vuln, you fix zlib, not 50% of the installed packages on
your system.
Some websites, and many web aplications, *require* java, javascript, cookies, etc. If you want a login page that does not involve sending the server your password then it is hard to imagine how to do it without client side scripting. One of the obvious implementations is a java applet.Banner ads: worse than you thought
>detecting all exploits would be a challengeBanner ads: worse than you thought
of the image format? I would expect that conforming images typically
cannot cause a buffer overflow.
No.Banner ads: worse than you thought
There's another point, other than security, in favour of trying to make image loading libraries as paranoid and robust as possible with their image handling.Image loading libraries
It would be some help to enable by default stack smashing protection--especially for Windows users who use the given binaries. There is already an issue filed for this:Banner ads: worse than you thought
(Sorry for posting again.) Another partial solution is deploying a system similar to Microsoft's HoneyMonkey project. This is a spin-off a honey pot. Instead, automated web browsers scoure the web looking for malware. When the malware is detected, two things happen: developers fix the problem in the browser, and someone maybe tries to shut down the malicious site.Banner ads: worse than you thought