In Firefox 95, we’re shipping a novel sandboxing technology called <\/span>RLBox<\/span><\/a> \u2014 developed in collaboration with researchers at the University of California San Diego and the University of Texas \u2014 that makes it easy and efficient to isolate subcomponents to make the browser more secure. <\/span>This technology opens up new opportunities beyond what’s been possible with traditional process-based sandboxing, and we look forward to expanding its usage and (hopefully) seeing it adopted in other browsers and software projects.<\/span><\/p>\n This technique, which uses WebAssembly to isolate potentially-buggy code, builds on the <\/span>prototype<\/span><\/a> we shipped last year to Mac and Linux users. Now, we\u2019re bringing that technology to all supported Firefox platforms (desktop and mobile), and isolating five different modules: <\/span>Graphite<\/span><\/a>, <\/span>Hunspell<\/span><\/a>, <\/span>Ogg<\/span><\/a>, <\/span>Expat<\/span><\/a> and <\/span>Woff2<\/span><\/a> [1]. <\/span><\/p>\n Going forward, we can treat these modules as untrusted code, and \u2014 assuming we did it right \u2014 even a zero-day vulnerability in any of them should pose no threat to Firefox. Accordingly, we\u2019ve updated our <\/span>bug bounty program<\/span><\/a> to pay researchers for bypassing the sandbox even without a vulnerability in the isolated library.<\/span><\/p>\n All major browsers run Web content in its own sandboxed process, in theory preventing it from exploiting a browser vulnerability to compromise your computer. On desktop operating systems, Firefox also isolates each site in its own process in order to protect sites from each other. <\/span><\/p>\n Unfortunately, threat actors routinely attack users by chaining together two vulnerabilities \u2014 one to compromise the sandboxed process containing the malicious site, and another to escape the sandbox [2]<\/span>. To keep our users secure against the most well-funded adversaries, we need multiple layers of protection.<\/span><\/p>\n Having already isolated things along trust boundaries, the next logical step is to isolate across functional boundaries. Historically, this has meant hoisting a subcomponent into its own process. For example, Firefox runs audio and video codecs in a dedicated, locked-down process with a limited interface to the rest of the system. However, there are some serious limitations to this approach. <\/span>First, it requires decoupling the code and making it asynchronous, which is usually time-consuming and may impose a performance cost. Second, processes have a fixed memory overhead, and adding more of them increases the memory footprint of the application. <\/span><\/p>\n For all of these reasons, nobody would seriously consider hoisting something like the XML parser into its own process. To isolate at that level of granularity, we need a different approach.<\/span><\/p>\n This is where RLBox comes in. Rather than hoisting the code into a separate process, we instead compile it into WebAssembly and then compile that WebAssembly into native code. This doesn\u2019t result in us shipping any .wasm files in Firefox, since the WebAssembly step is only an intermediate representation in our build process. <\/span><\/p>\n However, the transformation places two key restrictions on the target code: it can\u2019t jump to unexpected parts of the rest of the program, and it can\u2019t access memory outside of a specified region. Together, these restrictions <\/span>make it safe to share an address space<\/span><\/a> (<\/span>including the stack<\/span><\/a>) between trusted and untrusted code, allowing us to run them in the same process largely as we were doing before. <\/span>This, in turn, makes it easy to apply without major refactoring: the programmer only needs to sanitize any values that come from the sandbox (since they could be maliciously-crafted), a task which RLBox makes easy with a tainting layer<\/a><\/span>.<\/span><\/p>\n The first step in this transformation is straightforward: we use <\/span>Clang<\/span><\/a> to compile Firefox, and Clang knows how to emit WebAssembly, so we simply need to switch the output format for the given module from native code to wasm. For the second step, our prototype implementation used <\/span>Cranelift<\/span><\/a>. Cranelift is excellent, but a second native code generator added complexity \u2014 and we realized that it would be simpler to just map the WebAssembly back into something that our existing build system could ingest. <\/span><\/p>\n We accomplished this with <\/span>wasm2c<\/span><\/a>, which performs a straightforward translation of WebAssembly into equivalent C code, which we can then feed back into Clang along with the rest of the Firefox source code. This approach is very simple, and automatically enables a number of important features that we support for regular Firefox code: profile-guided optimization, inlining across sandbox boundaries, crash reporting, debugger support, source-code indexing, and likely other things that we have yet to appreciate.<\/span><\/p>\n RLBox is a big win for us on several fronts: it protects our users from accidental defects as well as supply-chain attacks, and it reduces the need for us to scramble when such issues are disclosed upstream. <\/span>As such, we intend to continue applying to more components going forward. Some components are not a good fit for this approach \u2014 either because they depend too much on sharing memory with the rest of the program, or because they\u2019re too performance-sensitive to accept the modest overhead incurred \u2014 but we\u2019ve identified a number of other good candidates. <\/span><\/p>\n Moreover, we hope to see this technology make its way into other browsers and software projects to make the ecosystem safer. <\/span>RLBox<\/span><\/a> is a standalone project that\u2019s designed to be very modular and easy-to-use, and the team behind it would welcome other use-cases.<\/span><\/p>\n Speaking of the team: I\u2019d like to thank <\/span>Shravan Narayan<\/span><\/a>, <\/span>Deian Stefan<\/span><\/a>, and <\/span>Hovav Shacham<\/span><\/a> for their tireless work in bringing this work from research concept to production. Shipping to hundreds of millions of users is hard, and <\/span>they did some seriously impressive work.<\/span><\/p>\n Read more about RLBox and this announcement on the UC San Diego Jacobs School of Engineering website<\/a>.<\/p>\n —<\/p>\n [1] Cross-platform sandboxing for Graphite, Hunspell, and Ogg is shipping in Firefox 95, while Expat and Woff2 will ship in Firefox 96.<\/p>\n [2] By using a syscall to to exploit a vulnerability in the OS, or by using an IPC message to exploit a vulnerability in a process hosting more-privileged parts of the browser.<\/p>\n —<\/p>\n","protected":false},"excerpt":{"rendered":" In Firefox 95, we’re shipping a novel sandboxing technology called RLBox \u2014 developed in collaboration with researchers at the University of California San Diego and the University of Texas \u2014 … Read more<\/a><\/p>\n","protected":false},"author":1610,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[449530,449215,449525],"tags":[],"coauthors":[465198],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/posts\/265"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/users\/1610"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/comments?post=265"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/posts\/265\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/media?parent=265"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/categories?post=265"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/tags?post=265"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blog.mozilla.org\/attack-and-defense\/wp-json\/wp\/v2\/coauthors?post=265"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The Limits of Process Sandboxing<\/strong><\/h2>\n
Isolating with RLBox<\/strong><\/h2>\n
Next Steps<\/strong><\/h2>\n