Chrome-plated holes

Seite 3: Patchwork

Patchwork

The exploits of the last months shattered Mozilla's image as a secure browser. Embarrassing crashes, known from Microsoft's worst days, only made things worse. There was a fix of a serious security problem. Thousands of users downloaded MBytes from the net to install the new version only to learn a short time alter that developers had disabled the demo exploit but left the hole wide open. A minor change in the exploit code made it work again.

Instead of patching holes here and there, it is about time to reconsider the security concept. Developers are aware of the situation: "we have done a crappy job lately, patching just symptoms and producing compatibility problems without fixing underlying security holes." Brendan Eich, inventor of JavaScript and Mozilla's chief architect rages in bugzilla.

The underlying security hole Eich is addressing is obvious. Two zones in Mozilla operate with different rights: the chrome, allowed to do everything, and the restricted part that handles code from untrustworthy sources. And the borders are becoming blurred because the two parts have to interact, exchange events, data and even code.

That is why the Mozilla team is working on separating those zones more sharply. They intend to track the origin of potentially dangerous elements like the afore-mentioned JavaScript URLs more consistently. This origin then decides what privileges they can achieve [2]. The more general solution of completely denying chrome privileges to javasccript: URLs was abandoned for compatibility reasons [3]. Furthermore, content and chrome are not to share DOM object wrappers any more [4]. And finally, developers are revising the event handling to protect the chrome from script generated events.

Because conceptual changes never go without breaking compatibility -- extensions don't work any more, pages may not be displayed correctly and so on -- they are being tested only in the development branch (1.1 for Firefox). Only patches without significant incompatibilities are to be ported back into the stable branch (Firefox 1.0). In the case of acute security problems, users of the stable versions have to settle with workarounds that stop exploits from working but do not address the real problem. This is often reserved for the trunk version, i.e. Firefox 1.1.

Wakeup Call

The very dedicated development community of the open source browsers has always succeeded in producing patches for published security problems very quickly. Users of Mozilla & Co. have not remained unprotected from known security hazards, which did happen with the Internet Explorer. So there are no known cases where security holes have been exploited to spread spyware and the like on a large scale.

But this can change any time. Criminal organisations already have their own experts who are able to discover and exploit security holes. This was proven quite impressively by the zero-day exploit for Internet Explorer analyzed by jelmer. It combined a couple of minor problems in a very complex way to achieve higher permissions.

This exploit was found in the wild, before the security problems were known to the public. As Mozilla and Firefox become more widespread, the danger increases that criminals will look for security loopholes and start to exploit them before developers even know about them. And the current versions of Mozilla and Firefox offer too much undefended area for such attacks. But the developers have heard the wakeup calls, and there is hope that the security provisions for Firefox 1.1 will pass the test.