Gibraltar: Exposing Hardware Devices to Web Pages Using AJAX
Total Page：16
File Type：pdf, Size：1020Kb
Gibraltar: Exposing Hardware Devices to Web Pages Using AJAX Kaisen Lin David Chu James Mickens Jian Qiu UC San Diego Li Zhuang Feng Zhao National University of Singapore Microsoft Research Abstract tion language (e.g, the Win32 API for Windows machines, Gibraltar is a new framework for exposing hardware devices or Java for Android). Both choices limit the portability of to web pages. Gibraltar’s fundamental insight is that Java- the resulting applications. Furthermore, moving to native Script’s AJAX facility can be used as a hardware access pro- code eliminates a key benefit of the web delivery model— tocol. Instead of relying on the browser to mediate device in- applications need not be installed, but merely navigated to. teractions, Gibraltar sandboxes the browser and uses a small device server to handle hardware requests. The server uses 1.1 A Partial Solution native code to interact with devices, and it exports a stan- To remedy these problems, the new HTML5 specifica- dard web server interface on the localhost. To access hard- tion [10] introduces several ways for JavaScript to access ware, web pages send device commands to the server using hardware. At a high-level, the interfaces expose devices as HTTP requests; the server returns hardware data via HTTP special objects embedded in the JavaScript runtime. For responses. example, the <input> tag [24] can reflect a web cam ob- Using a client-side JavaScript library, we build a simple ject into a page’s JavaScript namespace; the page reads or yet powerful device API atop this HTTP transfer protocol. writes hardware data by manipulating the properties of the The API is particularly useful to developers of mobile web object. Similarly, HTML5 exposes geolocation data through pages, since mobile platforms like cell phones have an in- the navigator.geolocation object [27]. Browsers imple- creasingly wide array of sensors that, prior to Gibraltar, were ment the object by accessing GPS devices, or network cards only accessible via native code plugins or the limited, incon- that triangulate signals from wireless access points. sistent APIs provided by HTML5. Our implementation of Given all of this, there are two distinct models for creat- Gibraltar on Android shows that Gibraltar provides stronger ing device-aware web pages: security guarantees than HTML5; furthermore, it shows that • Applications can be written using native code or plug- HTTP is responsive enough to support interactive web pages ins, and gain the performance that results from running that perform frequent hardware accesses. Gibraltar also sup- close to the bare metal. However, users must explicitly ports an HTML5 compatibility layer that implements the install the applications, and the applications can only run HTML5 interface but provides Gibraltar’s stronger security. on platforms that support their native execution environ- ment. 1. Introduction • Alternatively, applications can be written using cross- Web browsers provide an increasingly rich execution plat- platform HTML5 and JavaScript. Such applications do form. Unfortunately, browsers have been slow to expose not require explicit installation, since users just navigate low-level hardware devices to JavaScript [8], the most pop- to the application’s URL using their browser. However, ular client-side scripting language. This limitation has be- as shown in the example above, HTML5 uses an incon- come particularly acute as sensor-rich devices like phones sistent set of APIs to name and query each device, mak- and tablets have exploded in popularity. A huge marketplace ing it difficult to write generic code. Furthermore, by ex- has arisen for mobile applications that leverage data from posing devices through extensions of the JavaScript inter- accelerometers, microphones, GPS units, and other sensors. preter, the entire JavaScript runtime becomes a threat sur- Phones also have increasingly powerful computational and face for a malicious web page trying to access unautho- storage devices. For example, graphics processors (GPUs) rized hardware—once a web page has compromised the are already prevalent on phones, and using removable stor- browser, nothing stands between it and the user’s devices. age devices like SD cards, modern phones can access up to Unfortunately, modern browsers are large, complex, and 64GB of persistent data. have many exploitable vulnerabilities [4, 30, 34]. On mo- Because JavaScript has traditionally lacked access to bile devices, browsers represent a key infection vector for such hardware, web developers who wanted to write device- malicious pages that steal SMS information [21], SD card aware applications were faced with two unpleasant choices: data [23], and other private user information. learn a new plugin technology like Flash which is not sup- Ideally, we want the best of both worlds—device-aware, ported by all browsers, or learn a platform’s native applica- cross-platform web pages that require no installation, but whose security does not depend on a huge trusted computing and the device server is much simpler than a full-blown base like a browser. web browser; for example, our device server for Android phones is only 7613 lines of strongly typed Java code, 1.2 Our Solution: Gibraltar instead of the million-plus lines of C++ code found in Our new system, called Gibraltar, uses HTTP as a hardware popular web browsers. Using capability tokens and sen- access protocol. Web pages access devices by issuing AJAX sor widgets, Gibraltar can also prevent (or at least detect) requests to a device server, a simple native code applica- many attacks from malicious web pages and browsers. tion which runs in a separate process on the local machine HTML5 cannot stop or detect any of these attacks. and exports a web server interface on the localhost domain. • Usability: An HTTP device protocol provides a uniform If a hardware request is authorized, the device server per- naming scheme for disparate devices, and makes it easy forms the specified operation and returns any data using a for pages to access non-local devices. For example, a standard HTTP response. Users authorize individual web do- page running on a user’s desktop machine may want to mains to access each hardware device, and the device server interact with sensors on the user’s mobile phone. If a authenticates each AJAX request by ensuring that the refer- Gibraltar device server runs on the phone, the page can rer field [7] represents an authorized domain. access the remote hardware using the same interface that Unlike HTML5, Gibraltar does not require the browser it uses for local hardware—the only difference is that the to be fully trusted. Indeed, in Gibraltar, the browser is sand- device server is no longer in the localhost domain. boxed and incapable of accessing most devices. However, • Backwards Compatibility: It is straightforward to map a corrupted or malicious browser can send AJAX requests HTML5 device commands to Gibraltar calls. Thus, to run to the device server which contain snooped referrer fields a preexisting HTML5 application atop Gibraltar, a devel- from authorized user requests. To limit these attacks, Gibral- oper can simply include a translation library that converts tar uses capability tokens and sensor widgets [12]. Before a HTML5 calls to Gibraltar calls but preserves Gibraltar’s web page can access hardware, it must fetch a token from security advantages. The library can use Mugshot-style the device server. The page must tag subsequent hardware interpositioning [19] to intercept the HTML5 calls. requests with the fresh capability. Since Gibraltar uses HTTP to transport hardware data, a key To prevent a malicious browser from surreptitiously re- question is whether this channel has sufficient bandwidth questing capabilities from the device server, Gibraltar em- and responsiveness to support real device-driven applica- ploys sensor widgets. Sensor widgets are ambient GUI el- tions. To answer this question, we wrote a device server for ements like system tray icons that indicate which hardware Android mobile phones, and modified four non-trivial appli- devices are currently in use, and which web pages are using cations to use the Gibraltar API. Our evaluation shows that them. Sensor widgets help a user to detect discrepancies be- Gibraltar is fast enough to support real-time programs like tween the set of devices that she expects to be in use, and games that require efficient access to hardware data. the set of devices that are actually in use. Thus, sensor wid- gets allow a user to detect when a compromised browser is issuing hardware requests that the user did not initiate. Using these mechanisms, a compromised browser in 2. Design Gibraltar has limited abilities to independently access hard- Gibraltar uses privilege separation [29] to provide a web ware (x5). However, a malicious browser is still the con- page with hardware access. The web page, and the enclosing duit for HTTP traffic, so it can snoop on data that the user browser which executes the page’s code, are both untrusted. has legitimately fetched and send that data to remote hosts. Gibraltar places the browser in a sandbox which prevents Gibraltar does not stop these kinds of attacks. However, direct access to Gibraltar-mediated devices. The small, na- Gibraltar is complementary to information flow systems like tive code device server resides in a separate process from the TightLip [39] that can prevent such leaks. browser, and executes hardware requests on behalf of the page, exchanging data with the page via HTTP. 1.3 Advantages of Gibraltar As shown in Figure 1, a Gibraltar-enabled page includes Gibraltar’s device protocol has four primary advantages: a JavaScript file called hardware.js. This library imple- • Ease of Deployment: Gibraltar allows device-aware pro- ments the public Gibraltar API. hardware.js fetches au- grams to be shipped as web applications that do not need thentication tokens as described in Section 2.1, and trans- to be installed.