Browser Performance and Security After NPAPI

Tufts University Introduction to Computer Security COMP 116 Browser Performance and Security After NPAPI Author: Mentor: Sunjay Bhatia Ming Chow December 12, 2014 Contents 1 1contentsIntroduction 2 1.1 Origins of NPAPI . 2 1.2 Recent Developments . 2 2 To the Community 2 2.1 NPAPI Security Risks Due to Implementation . 2 2.2 NPAPI Security Risks Due to Features/Usage . 3 3 Defenses 4 3.1 Google’s Native Client . 4 3.2 asm.js . 5 4 Summary 6 5 Supporting Material 6 6 References 7 The Netscape Plugin Application Programming Interface (NPAPI), a cross- browserabstract API for plugins, is being phased out by Google and Mozilla, re- sulting in a new era for native code integration with the browser. NPAPI plugins are useful in providing increased performance and access to native operating system features but are also notorious for exposing security holes. This paper will attempt to give background on the problems that NPAPI plugins can cause and the benefits of no longer supporting this technology as we strive to move toward a more secure web. This paper will also give examples of newer technologies and the pros and cons of where the state of the art is headed, namely Google’s Portable Native Client (PNaCl, pronounced "pinnacle") and even asm.js. introduction 2 1 introduction With1.1 Origins the release of NPAPI of the Navigator browser by Netscape in 1994, user interac- tion with the web was becoming an important direction with which software manufacturers were taking their efforts. In particular, Adobe were hopeful that their PDF file format and reader would be able to be integrated with the web browser and not only be confined to the desktop. Shortly after the release of Navigator, Allan Padgett, one of the authors of the Acrobat Reader, and others were able to actually reverse engineer the browser and leverage the power of rendering a PDF within the browser window[7]. This could have simply stopped there, but "Allan’s Hack" was instead transformed into a extensible plugin interface that allowed developers to effectively extend the web and and utilize the functionality and power of the host computer. The1.2 useRecent of NPAPI Developments has grown exponentially, with developers and large com- panies alike developing plugins for the web to take advantage of what the interface to the host computer provides them. The web has changed and become quite dynamic since the early days, and NPAPI has definitely been a large part of that growth. Even with the widespread use of NPAPI, on September 23, 2013, the Chromium project announced the phasing out of this technology from the Chrome and Chromium browsers[2]. No new applications or extensions will be allowed in the Chrome webstore and users can only use plugins that have been whitelisted (because they are so widely used). In addition, Mozilla announced that they would eliminate support for these plugins. This does not come as a surprise to most security pro- fessionals, as there have been glaring holes in the NPAPI security model and implementation that have never been fully addressed. Removing the whole NPAPI infrastructure, though it is flawed, would definitely set web technology back quite a ways. Google and Mozilla however both are champi- oning their own solutions for replacing NPAPI with potentially more secure Portable Native Client and asm.js respectively. 2 to the community 2.1NPAPINPAPI plugins Security are notoriously Risks Due dangerous to Implementation because they have essentially "unrestricted" access to the local machine. Plugins are allowed to run native machine instructions with the same permissions as the host process (the browser). The implementation model allows these plugins to access features of the host machine in an unsupervised manner, which can be risky in many ways. If the permissions of the host process are sufficiently broad, [3] a malicious plugin would be able to take advantage .to If thethere community are security 3 vulnerabilities in a plugin because of badly written code, attackers can easily use them to install malicious software on a host computer completely silently without any knowledge to the user. This is especially prevalent because of the implementation language, C/C++ and the penchant developers have for not managing memory properly. Buffer overflow exploits should not be as big of an issue as they still are (because it seems like a "solved" problem), however NPAPI plugins still allow this attack vector to be open. Browser technology has improved greatly over the years and browsers are faster and safer than when NPAPI was originally designed and developed in the 1990s[2]. As a result, the NPAPI model is not up to date and the benefits of performance that we were able to champion in the past have been severely diminished. NPAPI "has become a leading cause of hangs, crashes, security incidents, and code complexity"[3]. 2.2NPAPINPAPI plugin Security interfaces Risks to Due the userto Features/Usage have clear flaws that introduce further security risks. The concept of the "Click to Play" plugin was introduced as a security measure in order for the user to determine when they wanted plugins to be used[7]. This is a flawed system because it relies on the user to to be savvy about the plugins they are using and only trusting safe plugins. The majority of users of the web are not able, and should not be made to make this distinction. Old and out of date plugins are not as a rule blocked and this poses another huge threat to security. We definitely do not want outdated code running unrestricted on our host computers. Figure 1: Example of "Click to Play" in Firefox As expected, the continued allowance of by Google and others of whitelisted plugins of course comes at somewhat of a risk. Users and administrators need to be aware that their plugins are potentially dangerous or vulnerable even if they are useful. In the short term this seems like an adequate stop- gap, but the whole NPAPI infrastructure does need to be removed to ensure long term safety. defenses 4 It is not all doom and gloom in the web plugin space. There have been advances3 defenses in recent years to bring more security and even more performance to browser plugins and the best of the bunch manifest themselves in the following solutions. 3.1PNaClGoogle’s (pronounced Native "pinnacle") Client is Google’s attempt at leading us away from the plugin model while still preserving performance. PNaCl allows developers to utilied the power of the host operating system, but in a fundamentally different way from NPAPI. Figure 2: Diagram of PNaCl and NaCl architecture Only trusted system calls are allowed to access the native featuresdefenses and 5 native code does not run in any sort of privileged state. The native C/C++ code must be essentially "vetted" by the sandboxing mechanism implemented in Chrome[4]. The general model can be seen in Figure 2. C/C++ code is written and compiled by the PNaCl toolchain. This toolchain compiles the code in a portable intermediate format that allows the code to be packaged and available to be distributed in Googles .pexe format[5]. The binary format is based on LLVM. The code is packaged as a resource and sent along with a web request. Chrome is able to verify the code as trusted, compile it to architecture specific code, and run it in the "sandbox" that it allocates for it. If the code is modified at runtime as part of a JIT compiling process, the code is run in a more secure "untrusted" sandbox and is restricted to what it can do. This model has stood up to rigorous testing and security review and the sandbox and static code validators can actually proved to be correct and safe which is a major win for this technology[4]. There are many existing applications and browser extensions that use NaCl (the less portable but more performant version of this technology) and PNaCl is an exciting direction for the web because it improves upon the portability as well as performance of existing plugins and code can be easily transformed to fit this model and format. The sandboxing model is one that that is very important to computer security as whole, not just in relation to browser applications. The paradigm that has been quite successfully implemented in PNaCl, of running untrusted code in a sandbox is a very difficult one to implement, but has also been used in Google’s Chrome OS. Android implements a version of this to an extent as well. 3.2asm.jsasm.js by Mozilla, on the other hand, is a subset of Javascript that is used primarily to improve performance of web applications written in statically typed languages that are then run through a source to source compiler and translated to Javascript[1]. C/C++ code is converted to LLVM bitcode. Mozilla’s Emscripten engine turns these bitcodes to JavaScript. The asm.js virtual machine has its whole virtual memory layout in a JavaScript typed array[1]. While the asm.js security model is not quite mature as of yet and has not been optimized, some features it introduces are quite helpful. Figure 3: asm.js model Translating unmanaged languages like C and C++ to Javascriptsummary already 6 solves issues of memory corruption and there are many other ways asm.js can help with security of these sorts of applications. If code had a buffer overflow vulnerability, once it is converted to Javascript and running in the asm.js virtual machine there are runtime checks that are built in to trigger exceptions and not allow any malicious behavior.

Load more