Over the past two months or so, Mozilla’s Firefox browser has garnered far less media attention than Google’s Chrome and Chromium projects …
… But Mozilla probably isn’t complaining this time around, since the last three consumer versions of Chrome have included security fixes for zero-day security vulnerabilities.
A zero-day is where crooks find an exploitable security hole before the good guys do, and start abusing that bug to do bad things before a fix exists.
The name reflects the annoying fact that there was no day you could have been one step ahead of the crooks, even though you’re the kind of prompt acceptance user who always corrects the same day you release them. software updates.
To be fair to the Chromium team, the most recent zero day hole, fixed in version 90 of the Chrome and Chromium projects, is best described as a half hole. You should do all you can to run the browser with its sandbox protection turned off, which you probably won’t do by choice and unlikely to do by mistake.
What’s in a name?
Fortunately, this month’s Firefox update (in fact, Mozilla’s updates come out every four weeks, always on a Tuesday, rather than once a calendar month) has drawn more attention to a new privacy feature that she included only for the security holes she removed.
When a browser page opens a new window or tab, it can give that new page a name (a tag or nickname, if you want), by which to later refer to the new tab as the target for opening some. additional content.
Here is an example of legitimate use of the
On our first attempt, we referred to the target tab
NEWTAB in the link on our page, and we’ve created a new tab using
window.open(), but we did not define a
window.namevalue for the new tab:
We get a page with the Naked Security site in a second tab, as well as a link in the first tab to open a third site, namely
However, since we haven’t set a window name for one of the two tabs already open, our link just opens in a third tab, sandwiched between the previous two:
Let’s make a little change and try again.
name property of the Naked Security tab when we open it, so that we can explicitly reference that second tab in the future, using the nickname
The main tab looks like last time:
Specifying an existing tab name in the link target means that we can reuse the second tab for our new content, so the
example.com the page opens in the same
NEWTAB tab, replacing the content of Naked Security and avoiding the creation of a third tab.
We end up with only two tabs, not three like last time:
This type of behavior can be useful in content management systems where you want a single “preview” page that updates as you edit your content, rather than leaving you with a new tab. open for each page you preview.
Window names considered dangerous
SOP is a fundamental part of web security because it prevents Site Y, which may be an unscrupulous marketing page or a phishing site run by scammers, from accessing personal data stored by Site X.
window.name the property could surreptitiously be misused to bypass the SOP because it has not been cleared between different sites.
We can see this behavior for ourselves, using the practical development tools in the current [2021-04-20T13:00Z] Edge version (based on Chromium).
Here we have opened the special web page
window.name variable to value
Now we have opened a page from a completely different area, namely
example.com, but we can see that the old value of
window.name has been moved to the new page, although you can expect the same-origin policy to prevent this from happening:
In other words, the modest
window.name variable can be used as a sneaky way to pass messages between different domains, bypassing the SOP, and therefore sharing tracking codes from one site to another when you don’t expect it.
Operated for years
According to Mozilla, web tracking companies have been exploiting this flaw for years:
Since the late 1990s, web browsers have made the window.name property available to web pages as a place to store data. Unfortunately, the data stored in window.name has been allowed by standard browser rules to leak between websites, allowing trackers to identify users or monitor their browsing history. […]
Tracking companies have abused this property to disclose information and effectively turned it into a communication channel for transporting data between websites. Worse yet, malicious sites were able to observe the contents of window.name to collect private user data that was inadvertently disclosed by another website, and decided to shut it down.
Since Firefox 88, things have changed:
To close this leak, Firefox now limits the window.name property to the website that created it.
Here’s the difference – we repeated the above activity in the Developer Console, this time using the new Firefox 88.
As before, we define the
window.name ownership when our domain name was
But when we moved on to
example.com, the previous value had been erased, and the
window.name variable returned as an empty string:
In even better news, Mozilla reports that other mainstream browser platforms are making the same kind of change, removing this tracking tip across the board:
Firefox isn’t the only one making this change: Web developers who rely on window.name should note that Safari also clears the window.name property, and Chromium-based browsers plan to do so. Going forward, developers should expect clearing to be the new standard way browsers handle window.name.
It’s a small change, of course, but it’s nice to see browser makers agreeing to do away with “features” of this sort in unison that are easily exploited by websites that don’t care. confidentiality.
Lots of bug fixes
As you would expect from a four week version of Firefox, there are also many security fixes in version 88.0.
None of them are considered critical, probably because no one has figured out how to turn the most dangerous bugs into real exploits yet.
Still, several of the bugs deal with potentially dangerous and exploitable memory mismanagement, including a buffer overflow (where you write to the wrong part of memory) and two post-free usage bugs (where you write to a memory that has already been rotated for use elsewhere).
Using common Mozilla terminology, the Firefox developers documented all of these bugs by admitting that “we assume that with enough effort, some of them could have been exploited to execute arbitrary code.“
Rather than wait for someone – hopefully a cybersecurity researcher willing to responsibly disclose new exploits, rather than just selling them on the open market – to prove the bugs were really dangerous, the team corrected them anyway.
Other bugs fixed included so-called “presentation” bugs, where a user might think they were on site X when they were not.
As you can imagine, phishers love this type of bug because it helps them pass fake content off as real, even to users who are monitoring their presence on the website they expect.
What to do?
If you are on Windows or Mac, go to Help > About Firefox or for Firefox > About and check if you are up to date.
If not, the version check will prompt you to update immediately.
If you are on Linux, your version of Firefox can be managed as part of your distribution, so Help > About can just show you which version you are on, without performing an explicit update check. (At 2021-04-20T13: 00Z, you are looking for Firefox 88.0.)
Check back with your distro’s package manager for the latest version.
On iOS and Android, you can update from the App store or google play respectively, but note that on an iPhone, Firefox uses Apple’s browser kernel (which does not yet have the
window.name fix), and on Android, the latest version number may vary from device to device.