Chrome-plated holes

It's gone, the myth of invulnerability of Mozilla users: one wrong click may be enough to infect your system with spyware -- even if you are using Mozilla or Firefox. The reasons are quite similar to well known security holes in Internet Explorer.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 11 Min.
Inhaltsverzeichnis

In the last few years, Microsoft's Internet Explorer has mainly drawn attention for its security problems. Again and again security holes were published that allowed spyware and trojans to be installed on user systems without the user doing anything more than opening an infested Web site; other times, some minimal action was required such as clicking or performing drag&drop on the page. Those holes were and are still actively exploited to download Spyware and Trojans onto the systems of unwary users.

The unholy trinity of ActiveX, Active Scripting and the local zone was responsible for a lot of these problems. Special Active X components provide methods for writing and activating files from within IE. With Active Scripting, those actions can be remotely activated. And for all this to work, the code has to be executed in the security zone of the local system. What is less commonly known: Mozilla & Co. offer quite similar concepts. And they are responsible for some of the serious security holes published during the last few months that damaged the reputation of Mozilla as a safe alternative to IE.

Usually, only pages originating from the system they are opened on -- such as with a file:-URI -- have these privileges in IE. Writing an IE exploit, for example to install spyware from an external web site, therefore means that hackers have to find a way to get those rights of the local zone. But before XP Service Pack 2, many roads led to Rome.

It is especially well known that the function to present local help files opened the doors to the local zone again and again. For example, one exploit opened a help window, planted shortcuts with the JavaScript function document.write(), and activated them with scripted mouse click events. Once in the "local system” zone, objects like ADODB.Stream, Shell.Application or WScript.Shell delivered access to the required system functions to write files and execute programms. But SP2 (almost) put an end to this. Even the security researcher http-equiv, who discovered and documented dozens of serious IE flaws, stated that SP2 did a good job with securing IE loopholes. For one, Microsoft tightened access to the local zone; second, they deactivated functions for writing and starting files from within IE like ADODB.stream and Shell.Application.