Perpetual IT

Today’s a Firefox Tuesday, when the latest version of Mozilla’s browser comes out, complete with all the security updates that have been merged into the product since the previous release.

We used to call them Fortytwosdays, because Mozilla followed a six-weekly coding cycle, instead of monthly like Microsoft, or quarterly like Oracle, and seven days multiplied by six weeks gave you the vital number 42.

These days, Mozilla mostly goes for four-week cycles, so that updates shift around steadily in the monthly calendar in the same sort of way that lunar months slide gradually across the solar year.

This update brings the mainstream version to 95.0, and includes a bunch of security fixes, listed in Mozilla Foundation Security Advisory MFSA-2021-52, including vulnerabilities leading to:

• Numerous crashes that could potentially be wrangled into exploitable holes.
• WebExtensions that could leave behind unwanted components after official uninstallation.
• Tricks to permit remote sites to find out some of the apps installed on your computer.
• Sandbox bypasses that could allow untrusted scripts to do more than intended.
• Tricks to put the cursor in the wrong place, potentially disguising risky clicks.

To make sure you have the latest version, go to Help > About and wait for the animated line Checking for updates... to tell you if there’s an update available.

Note that on Linux and some Unixen, Firefox might be delivered as part of your distro, so check there for the latest version if Firefox doesn’t offer to update itself.

A whole new sandbox

The big change in Firefox 95.0, however, is the introduction of a new sandboxing system, developed in academia and known as RLBox.

(We have to admit that we can’t find an official explanation of the letters RL in RLBox, so we’re assuming they stand for Runtime Library, rather than denoting the initials of the person who initiated the project.)

Strict sandboxing inside a browser is often achieved by splitting the browser into separate system procesess for each tab, which end up isolated from each other by the operating system itself.

By default, processes can’t read or write each other’s memory, so that a remote code execution hole triggered by a criminally-minded site such as dodgy.example doesn’t automatically get the ability to snoop on the content of a tab that’s logged into your email server or hooked up to a social networking account.

But not all parts of a browser’s rendering functionality are easy to split into separate processes, notably if an existing process loads what’s known as a shared library – typically a .DLL file on Windows, .so on Unix and Linux, and .dylib on macOS.

Shared libraries, for example to render a specific sort of font or to play a specific sort of sound file, are designed to run “in-process”.

That means they’re loaded into the memory space of the current process, pretty much as if they’d been compiled into the application right from the start.

In other words, a web page that can be tricked into loading a booby-trapped font will typically end up processing the risky font file right inside the same process that’s handling the rest of the page.

You’d get better protection if the web renderer and the font handler could run separately, and didn’t have access to each others’ memory and data, but that’s tricky to do in a world in which you’re already using shared libraries to provide additional per-process features.

You’d need to go back to the drawing board and reimplement all the functions currently implemented via shared libraries (which, as the name suggests, share memory and other run-time resources with the parent process) in some other way.

Gallia est omnis divisa in partes tres

RLBox is a way to simplify the process of splitting your processes into separate parts, so that your code doesn’t need a complete rewrite.

Nevertheless, RLBox calls into shared libraries pass through a “separation layer” that keeps apart the inner workings of the main program and at least some of its libraries.

Your code still needs changing to let RLBox intervene in how data is passed back and forth between the main application and its shared-library subroutines, but the amount of upheaval in adding these security checks is, at least if the RLBox team and the Firefox developers are to believed, comparatively modest and easy to get right.

Notably, according to the RLBox team:

Rather than migrating an application to use RLBox […] in a single shot, RLBox allows ‘incremental migration’ […] Migrating existing code to use RLBox APIs can be performed one [operation] at a time. After each such migration, you can continue to build, run [and] test the program with full functionality to make sure the migration step is correct.”

Unfortunately, not many of Firefox’s rendering functions have yet been switched to RLBox.

Apparently, only a few special font-shaping operations, the spelling checker, and the media-playing code for OGG files have been moved into this more secure mode.

OGG files are the ones you often find on Wikipedia and zealous free-and-open-source websites, because the OGG codecs have never been encumbered by patents, unlike many other audio and video formats. (Codec isn’t as high-tech a word as you might expect, by the way: it’s short simply for coder-and-decoder, in the same way that a modem is a signal modulator-and-demodulator.)

What next?

If all goes well, RLBoxed handling of XML files and WOFF fonts (the now-ubiquitous file format for embedded web fonts) will follow in Firefox 96.0.

Presumably, if that all goes well, the Mozilla team will continue to divide and conquer its browser code in order to create ever-smaller “zones of compromise” associated with each programming library (of which a typical browser session may require hundreds) that is needed to process untrusted content from outside.

Of course, if that doesn’t work, there’s always Lynx, as we discussed in a recent Naked Security Podcast.

Lynx is a browser so old-school and so stripped down that it doesn’t do fonts, JavaScript or even graphics: just 100% terminal-style text-mode browsing with a minimal reliance on shared libraries…

---