Thanks to Sophos exploit experts Mark Loman and Andrew O’Donnell for
their behind-the-scenes work on this article.
If you’re a Firefox user or, even more importantly, a Tor Browser user, make sure you have the latest update.
An zero-day exploit has been found in the wild that tricks an unpatched browser into making a web connection to a network address in Portugal.
TCP network connections include, as part of the protocol, the IP address of both the sender and recipient, so just attempting this connection gives away the true IP number of your computer, even if you’re browsing anonymously via Tor.
That means crooks (or law enforcement officers, or intelligence agents) who can entice you to visit a hidden site somewhere in the Tor network can use this exploit on their webserver to tie your real IP number to your activities on the dark web.
If the computer in Portugal should answer the connection request, the code in the exploit sample we examined will transmit an HTTP request that contains your MAC address (the unique identifier of your network card) and your computer name.
That’s a pretty serious degree of de-anonymisation.
If you’re a Firefox user who isn’t worried about anonymity, this exploit is still a serious problem, because the crooks could easily change the payload to install malware without you knowing.
That malware could be ransomware, a keylogger, a password stealer, a zombie to blast out spam, a DDoS attack bot, or any of a number of money-making criminal tools.
According to Mozilla, the bug that makes this exploit work, dubbed CVE-2016-9079, is what’s known as a use-after-free, or UAF for short.
The buggy code appears in the part of Firefox that deals with reading and displaying SVGs, or Scalable Vector Graphics files.
SVGs are widely used on the web these days for line drawings and logos because they are converted from lines, circles, blocks and so on into images only at the moment they are displayed.
That means that they don’t get blurry or pixellated, like regular images do, when you change the size of your browser window.
UAF explained
Simply put, a UAF bug means that the faulty part of the program asks the system to allocate it a block of memory, uses that memory for temporary data storage, hands the memory back when it’s no longer needed…
…then forgets that it freed up the memory, and accidentally uses it again later on.
As you can imagine, in a busy app like a browser, in which there are typically numerous threads of program execution happening at once, there’s a good chance that the freed-up memory will have been reassigned to some other component of the program before it gets re-used by the buggy part.
By a process of trial and error, crooks may be able to figure out a sequence of operations, usually orchestrated using JavaScript inside the browser, that ends up with the contended memory region being allocated to them.
At this point, the crooks are in the driving seat for two reasons:
- If the buggy code writes private browsing data into that region (such as personal information that shouldn’t be visible via JavaScript), the crooks can read it at their leisure.
- If the buggy code makes any decisions based on data in that region (such as a memory address that determines the executable code to run next), the crooks can control the browser.
As we mentioned above, this exploit came to light because it was already being used with malicious code that could uncloak the identity of Tor Browser users.
But we also noted that the payload part of the exploit could easily be switched to serve other purposes, such as drive-by installs of malware.
Drive-by installs are program downloads that bypass any of the usual browser dialogs and warnings, and that can therefore take even the most watchful user by surprise.
Thats why updating is critical: the crooks already know how to exploit this hole, and are apparently doing so.
What to do?
The version numbers you should see if you are up-to-date are:
- Firefox 50.0.2
- Firefox ESR 45.5.1
- Thunderbird 45.5.1
- Tor Browser 6.0.7 (based on Firefox ESR 45.5.1)
ESR is short for Extended Support Release. Loosely speaking, the first and second version numbers add up to the main version number of the regular Firefox release. So, 45.5 has the security fixes of version 45+5 = 50, but hasn’t taken any of the feature updates of the 50-45 = 5 interim releases. Thunderbird is listed here, even though it’s an email program, because it contains the same web rendering components as Firefox so that it can correctly display HTML email.
To check which version you have, use the About Firefox
, About Tor Browser
or About Thunderbird
menu items.
These appear under the Help
menu on Windows or under the app’s name in the menu bar on macOS.
If you aren’t up-to-date, the About
window should advise you and download the update for you; you’ll need to restart the program to switch from the old version to the new one.
Note. Sophos products such as Endpoint Security, UTM and XG Firewall detect and block this attack as Troj/ExpJS-NM. The Sophos Intercept X anti-exploit product blocks it at run time as a Stack Pivot exploit.
(No video? Watch on YouTube. There is no audio.)
Anonymous
To be a bit more precise, SVG uses equations, points and other mathematics to define the image to draw. It’s saved in XML format.
They don’t get blurry because the values are relative and scale with size changes. Compared to bitmapped graphics, which are a fixed size and can only be stretched or shrunk.
E.g. If have a circle with a diameter half the canvas size. The canvas size is 400px, so your circle diameter is 200px. You maximise your browser window, so the canvas size is now 800px. The circle still needs to be half the canvas size, so the browser resizes the circle diameter to 400px.
Paul Ducklin
I may have been a bit simplistic, but I think that “lines, circles, blocks and so on” is an acceptable and comprehensible alternative for “equations, points and other mathematics” :-) Especially when you consider the most widely-used primitives in SVG include <line>, <circle>, <rect> and <polygon>.
The reason SVGs don’t come out blurry is not specifically because they are defined in the source file as vectors, but because they are converted into the actual bitmap that gets displayed *only at the time they’re displayed* (rather than once up front), and thus have as much or as little detail as will fit at the required size. In other words, they’re scaled, stretched, shrunk and so on fresh each time, unlike a pre-rendered bitmap.
Anyway, we’re both right, so thanks for the comment!
Chuck
Just curious. What would they get for a MAC address and computer name if you’re using a virtual machine?
Paul Ducklin
They’d get the MAC address and name (on Windows, what you see if you use the command echo %COMPUTERNAME%) out of the VM. They’d get the IP number of the host computer, of your router/firewall/gateway if your local network is NATted, or of your VPN if you are VPNned.
IIRC, most virtual machine apps make up MAC addresses for each guest consisting of 3 prefix bytes denoting the VM software and 3 random bytes as a suffix, but you can change this to whatever you like.
Chuck
Thanks for explaining that. I also wondered if Noscript would block the website and possibly protect against this?
I assume that ad tracking websites could use this to identify users who are connected to a VPN. It’s getting harder and harder to be anonymous with new tricks like browser fingerprinting and that sort of thing.
Paul Ducklin
The claimed “in the wild” attack relies on JavaScript so Noscript ought to block it.
Chuck
Thanks!