The World Wide Web has grown tremendously over the last years. To make the rich and dynamic content on the Web accessible to end users, Web browsers have evolved rapidly as well, and new functionalities, often in the form of extensions and plug-ins, are added continuously. As is frequently the case with software, the significant increase in the size and complexity of the code that drives browsers and their extensions has resulted in an increase of program flaws (bugs). Some bugs simply crash the browser. Others, unfortunately, are security vulnerabilities that attackers can use to compromise end users’ machines, install malware, and steal sensitive information. Indeed, browser and extension vulnerabilities have become the primary venue through which cyber criminals compromise the security of Web users and, ultimately, earn money.
To prevent attackers from exploiting program flaws, it is critical to identify and fix bugs before the software is deployed. This is particularly important as users are slow in upgrading, even when patches are eventually made available. Expecting developers to write software that is free of any errors is unrealistic. Hence, we need tools that can automatically detect bugs, especially those that can be exploited by attackers.
The following paper describes VEX, a system that specifically focuses on the identification of security vulnerabilities in browser extensions for Firefox. These extensions are JavaScript add-ons that provide new functionality or augment existing features for the Firefox browser. In contrast to the core browser, extensions are often developed by programmers who have less experience in writing secure, robust code. Thus, a tool such as VEX is of particular importance to ensure a secure Web experience.
At the core of VEX is a static source code analysis component that checks for security vulnerabilities that are the result of potentially unsafe data flows. That is, the system scans the JavaScript code of an extension for program paths over which untrusted input, possibly controlled by an attacker, might reach security-relevant functions. If such a path exists, it could be possible for an attacker to craft malicious input that tricks the security-relevant function to do something that was not intended by the developer. For example, attackers could include malicious code in inputs, and this code is later executed by the extension in the context of the browser. This can lead to all kinds of security problems—for example, the attacker could steal a cookie and take over the session between the victim and an online banking site, or the attacker could steal passwords directly from form fields, or he could display a convincing phishing site to the user. Of course, VEX does not find all possible security vulnerabilities, but it covers an important class of common and critical bugs. As always with security, there is no single approach that solves everything, and this system is an important step into the right direction.
The crucial challenge the creators of VEX had to overcome is that static code analysis is a difficult problem. While precise static analysis is hard in general, it is particularly difficult for programs written in JavaScript. The reason is that JavaScript is a very dynamic language. It can execute code dynamically; that is, some parts of the program that will be executed during runtime do not exist in the source code. Instead, they are built by the application while it is running. Moreover, a Firefox extension does not work in isolation, but is tightly integrated with the browser. This means it calls many functions offered by the browser, for example, to access Web pages. Thus, the static analysis cannot look at the program in isolation but must take into account these interactions with the browser as well. I encourage you to read this paper to discover how the authors achieved this analysis.
A tool such as VEX is of particular importance to ensure a secure Web experience.
Static analysis is great because it covers all program paths. However, sound static analysis is also known to raise many false positives (that is, the system claims there is a vulnerability when there is none). VEX strives to strike a balance between trying to cover as many vulnerabilities as possible while making sure that false alarms are minimized. That is, although mistakes are possible, the false positive rates are low. This makes the system useful in practice. After all, for each alert, a human must manually investigate the reported problem.
The authors have demonstrated that VEX works well in practice by running it over 2,460 extensions. The system found a number of security problems, including seven vulnerabilities that were previously unknown. Examples of these bugs, as well as the details of VEX, are detailed in the paper.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment