Security testing
Scanit offers penetration tests, vulnerability assessments and web application audits.
Learn ethical hacking.
Scanit offers 5-day training on ethical hacking.

A Year Of Bugs

Page 2 out of 5 Previous page Next page

Browser Track Record Comparison

Three broad categories of browser bugs qualify as "remote code execution". The first category includes bugs related to the C or C++ programming language (all three browser families are written in those languages). It includes buffer overflows, integer overflows, and so on. Those bugs allow a malicious web page to inject machine code into the browser program and make the browser execute it. We do not include the tests for this kind of bugs into the Browser Test because they usually crash the browser, preventing the user from seeing the result of the test.

The second category of problems consists of "script execution" bugs. They happen when the browser fails to properly restrict the scripts or applets, and allows them to perform security sensitive actions, such as writing local files or starting programs. "Script execution" bugs do not always equal "remote code execution". JavaScript, which was designed as a web scripting language from the start, does not provide the programmer any ability to access files or start programs. The Java language has these capabilities, but Java applets run in so-called "sandbox", which is supposed to stop them from accessing files or programs.

The picture is different for Internet Explorer, where "script execution bugs" often result in remote code execution. HTML and JavaScript allow easy creation of versatile user interfaces. Microsoft recognized this and provided the tools to use Internet Explorer as a user interface for applications running locally. However in order to be able to make useful applications they need the ability to talk to other programs and access files. ActiveX controls - programs that can be loaded from a web page - provide that ability. The need to distinguish between possibly hostile Internet web pages and friendly local applications resulted in the security zone design of Internet Explorer. Internet Explorer assigns a security zone to a web page depending on the page's origin. Pages on the Internet are in the "Internet" security zone and pages residing on the hard drive are in the "Local Machine" security zone. Scripts on pages in the "Local Machine" zone have fewer restrictions on what they can do. In particular they can often call "dangerous" ActiveX controls that provide the ability to read or write files and execute programs. So, "script execution bugs" that can convince Internet Explorer that the script received from the Internet actually belongs in the "Local Machine" zone can usually be leveraged to execute arbitrary code, thus becoming "remote code execution".

Java is another programming language available to web developers. Failure of the Java sandbox to properly restrict Java applets can also result in "remote code execution" and affects all browsers that use Java.

The third category of problems includes user interface problems. Those are the ones that let a malicious web page trick a user into unknowingly performing a dangerous action, for example downloading and running a program. It can be as easy as getting the user to click a link. Browser Security Test does not check for this type of bugs, because testing them requires user interaction.

The picture above provides some insight into the security level of an Internet user, but does not answer the question "Which browser is most secure?". While we could provide a similar picture for various browsers it would not be objective. It would reflect what vulnerabilities we test, rather then what browsers are vulnerable.

Instead we decided to track the life spans of vulnerabilities discovered or fixed during 2004. We have compared the three most popular browser families - Microsoft Internet Explorer, Mozilla (including Firefox, Netscape and other Mozilla-based browsers) and Opera. To make our task easier we only looked at "remote code execution" bugs. By "remote code execution" we mean bugs that allow a malicious web page or e-mail message to execute arbitrary code or OS commands on the viewer's computer.

We tried to compare how fast the bugs get fixed after they are discovered in the three browser families. The three browsers have different development and update models, so we tried to find a way to compare "apples to apples".

Let us look at the typical lifespan of a vulnerability. First the vulnerability is discovered. It can be discovered either by the developers of the vulnerable program or by an external researcher. The discoverer of the vulnerability can either report the vulnerability to the public, report it privately to the program's development team, or use the vulnerability for malicious purposes. (Of course he or she can just keep it quite without using or abusing it). Even if the vulnerability was reported privately to the program's development team, the discoverer of the vulnerability can still decide to publish it at some point if he thinks that the fix isn't coming up soon enough. When the development team learn about the vulnerability they start working on a fix. The developers make the necessary changes to the source code of the browser to fix the vulnerability, then the changes are tested and finally the fix needs to be distributed to the users.

Internet Explorer and Opera are closed source software, Mozilla is open source. That means that anyone can get Mozilla's source code, while IE's and Opera's sources are only available to their respective development teams. In theory that means that Mozilla users can fix the discovered Mozilla vulnerabilities on their systems as soon as the fix is committed to the source code repository by the Mozilla development team. In practice fixing requires downloading the sources from source code repository and compiling the browser from source code. Rather small percentage of Internet users have the ability and the desire to do that. Most users will wait for a release or a patch from the vendor.

The fixes for Internet Explorer vulnerabilities are distributed as "security updates". Opera and Mozilla incorporate the fixes into the next version release. To make a comparison we have counted the time from the public announcement of the vulnerability to the time when the fix is available to the general user population. For Mozilla and Opera we have also recorded the time when the bug was reported to the development team. We didn't do that for Internet Explorer to avoid the clutter.


Page 2 out of 5 Previous page Next page