Firefox latest update brings new sort of security sandbox
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.
- 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.