Finding and Preventing Bugs in JavaScript Bindings

JavaScript, like many high-level languages, relies on runtime systems written in low-level C and C++. For example, the Node.js runtime system gives JavaScript code access to the underlying filesystem, networking, and I/O by implementing utility functions in C++. Since C++'s type system, memory model, and execution model differ significantly from JavaScript's, JavaScript code must call these runtime functions via intermediate binding layer code that translates type, state, and failure between the two languages. Unfortunately, binding code is both hard to avoid and hard to get right. This paper describes several types of exploitable errors that binding code creates, and develops both a suite of easily-to-build static checkers to detect such errors and a backwards-compatible, lowoverhead API to prevent them. We show that binding flaws are a serious security problem by using our checkers to craft 81 proof-ofconcept exploits for security flaws in the binding layers of the Node.js and Chrome, runtime systems that support hundreds of millions of users. As one practical measure of binding bug severity, we were awarded $6,000 in bounties for just two Chrome bug reports. Violation type Possible consequence Crash-safety DOS attacks, including poison-pill attacks [46]; breaking language-level security abstractions, including [42, 43, 95, 110], by introducing a new covert channel. Type-safety Above + type confusion attacks which, for example, can be used to carry out remote code execution attacks. Memory-safety Above + memory disclosure and memory corruption attacks which, for example, can be used to leak TLS keys [29] or turn off the same-origin policy [83]. [Constructor(DOMString[] blobParts)] interface Blob readonly attribute unsigned long size; readonly attribute DOMString contentType; Blob slice(optional unsigned long start, optional unsigned long end); ;