Firefox 88 fixes bugs, eliminates sneaky JavaScript tracking trick – Naked Security
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 is probably not complaining this time, given that 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 everything possible 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 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.
The “child problem” that Firefox just addressed is a lesser-known JavaScript variable called window.name
.
When a browser page opens a new window or tab, it can give that new page a name (a tag or nickname, if desired), by which to later refer to the new tab as the target for open additional content.
Here is an example of legitimate use of the window.name
property.
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.name
value 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 example.com
:
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.
This time we have included a line of JavaScript to define the 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 NEWTAB
:
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 is constantly updating as you edit your content, rather than leaving you with a new tab open for each page. as you preview.
Window names considered dangerous
Unfortunately the window.name
the property does not follow the so-called Same-origin policy (SOP), where only cookies and JavaScript variables set by the X website can be read by the X website.
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.
After all, data typically stored in site-specific JavaScript variables or cookies can include details such as your username, login secret (actually the password for the current session), your profile, and your preferences, the current contents of your basket, etc. After.
So, the SOP exists not only to prevent personal web data from inadvertently leaking between different websites, but also to prevent companies from sneakily following you by sharing data through innocent-looking JavaScript variables that you wouldn’t care about. other.
And the window.name
value was, at least until Firefox 88, one of those innocent but open to abuse JavaScript settings.
the 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 about:blank
, which is just a blank HTML page with a domain name that doesn’t match any other website, and we used the JavaScript console to set the window.name
variable to value pass-it-on-to-the-next-site
:
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 about:blank
:
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.