Security This New Firefox Feature Could Stop Zero Day Flaws In Their Tracks

The sandboxing technology was co-developed by researchers at Mozilla, the University of California, San Diego, the University of Texas, Austin, and Stanford University.  Mozilla released a preview of its for Firefox on Linux and macOS last December and has now extended it to Firefox for Windows, iOS and Android, according to Mozilla.   SEE: A winning strategy for cybersecurity (ZDNet special report) RLBox works by separating third-party libraries from an app’s native code. The first modules it isolates are Graphite, Hunspell, Ogg, Expat and Woff2, with RLBox protecting Firefox against attacks on vulnerabilities in these libraries.  “Going forward, we can treat these modules as untrusted code, and – assuming we did it right – even a zero-day vulnerability in any of them should pose no threat to Firefox,” Mozilla announced in a blogpost.  One aspect of browser security Mozilla wanted to address with RLBox was that Firefox is written with millions of lines of C and C++ code, which are prone to memory-related security flaws. While new components are written in memory-safer Rust, C/C++ code is expected to remain in the browser. RLBox will make it easier to isolate chunks of code in a more granular way that wasn’t possible with process-level sandboxing.  Firefox already runs each site in its own process. However, hackers can still chain together two vulnerabilities to, for example, escape the sandbox. “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’t result in us shipping any .wasm files in Firefox, since the WebAssembly step is only an intermediate representation in our build process,” Mozilla explains.  RLBox should also help respond to software supply chain attacks and the need to rush out patches for issued disclosed by upstream projects. RLBox sandboxing uses WebAssembly (Wasm), allowing it to compile modules to WebAssembly and then compile Wasm to native code using the wasm2c compiler, according to Shravan Narayan, the UC San Diego computer science PhD student leading the project.  “By compiling to Wasm before native code, we get sandboxing for free: We can ensure that all memory access and control flow will be instrumented to be confined to the module boundary,” said Narayan.