A nonet of security researchers are on the warpath to protect the Tor Browser from interfering busybodies.
Tor, short for The Onion Router, is a system that aims to help you be anonymous online by disguising where you are, and where you are heading.
That way, nation-state content blockers, law enforcement agencies, oppressive regimes, intelligence services, cybercrooks, Lizard Squadders or even just overly-inquisitive neighbours can’t easily figure out where you are going when you browse online.
Similarly, sites you browse to can’t easily tell where you came from, so you can avoid being traced back or tracked over time by unscrupulous marketers, social engineers, law enforcement agencies, oppressive regimes, intelligence services, cybercrooks, Lizard Squadders, and so on.
Note that the aim of Tor is not to add encryption to your network traffic so you can be lazy and not bother. Tor can’t add end-to-end encryption – by definition, that’s up to you and the server at the other side. But tor can disguise the whence and the hence of your network packets, thus helping you to preserve your anonymity.
Of course, Tor, or at least the use of Tor, has a bad side: cybercrooks, terrorists, illegal drug sellers, child abusers and worse can use it to keep the law off their backs.
For that reason, finding exploitable bugs in the Tor browser (it’s a repackaged, pre-configured version of Firefox’s Extended Support Release) is a hot topic.
Because the Tor browser runs right on your computer, before any of your traffic goes into Tor’s anonymising system, the browser process – if tricked or abused – could uncover details such as your login name, your computer name, your IP address, which ISP you are using, and much more.
Law enforcement, amongst others, are keen to find such bugs, which can be a huge help in tracking down criminals such as online child abusers, whose odious activities may otherwise be hard to uncover. (Courts don’t always agree with this sort of investigative practice, but that’s an issue for another day.)
And if law enforcement can find bugs, then cybercrooks and oppressive regimes can find them too, which could make life difficult even for Tor users whose motives are entirely noble.
That’s why our thoughtful research ninesome, by names Conti, Crane, Frassetto, Homescu, Koppen, Larsen, Liebchen, Perry and Sadeghi, have come up with a new exploit prevention tool called Selfrando, in a paper that will be presented in July 2016 at a privacy conference in Germany.
Selfrando isn’t just applicable to the Tor Browser, and the researchers say that they’ve used it successfully against a wide range of applications, including GNU Bash (the standard command shell on Mac OS X and many Unix/Linux distros), Google’s Chromium browser (the non-proprietary version of Chrome), and the popular Nginx web server.
Today’s exploits
As you may be aware, a lot of exploits these days require an attacker to find snippets of executable code that are already in memory, ready to run, that can be stitched together in sequence to perform malicious operations.
The old trick, common until the mid-2000s, was simply to use a buffer overflow, jam your own snippets of executable “shellcode” into memory on your victim’s computer, and trick the buggy application into running your malicious code. But that doesn’t work reliably any more, because most operating systems now support DEP, or data execution prevention. Any memory that you can write data into cannot also be used to execute machine code from. You can easily lead your shellcode to water, but you can no longer make it drink.
To prevent attackers abusing already-loaded program code, the usual defence is ASLR, short for address space layout randomisation, whereby programs load at different locations in memory every time.
Simply put, attackers can’t easily guess which fragments of code will be at what point in memory, so an exploit that works on their test computers probably won’t work out in the real world.
Raising the bar
But our Tor defenders want to raise the bar still further.
ASLR at the operating system level typically works program-by-program (or, more precisely, shared library by shared library), as you can see here:
This shows where Internet Explorer and its various system-level components ended up on three different reboots of Windows 7 32-bit.
But even though the locations are randomised, they aren’t randomised that much, because there are only so many permutations, and only so much space to juggle them in.
Furthermore, core system DLLs like ntdll.dll and kernel32.dll only get randomised when they first load during bootup, meaning that they may stay at the same address for days or weeks at a time.
To determined and patient crooks, that may be far too long: if the attackers get lucky once, they’ll remain “lucky” (because they now know the right address) until you reboot.
Selfrando goes much further, randomising the order of all the individual machine code functions in the protected program every time it loads, thus making it exponentially harder for attackers to predict in advance where the code fragments they need are going to be.
As you can imagine, that’s a much bigger job than just shifting around some system DLLs once every reboot.
Traditional ASLR is a bit like scrambling the order of the books on your shelf every month or so: once you’ve tracked down where Donald Knuth’s The Art of Computer Programming Volume 1 landed up after the last reshuffle, you’ll know where to find it in future.
Selfrando is more like reordering the individual chapters in every book, every time you open it to read it: much, much harder to predict or exploit.
Of course, if you shuffle around the pages in a book, there’s a lot of additional housekeeping you need to do as well, such as updating the table of contents and the index, as well as adding a note at the end of each chapter to say where to go next, and so forth.
That’s what Selfrando needs to do at a programming level, which is why it’s not as simple in practice as it sounds here in theory.
What now?
The authors claim that Selfrando is working pretty well already, and, as mentioned above, it works on a number of other applications, too.
If you’re even mildly technical, give the paper a read, because it contains a very handy list of references to explain how the exploit prevention “arms race” has unfolded in the last few years.
What’s good to protect Tor from exploits is a handy technique for the rest of us, too.
It’s worth reminding yourself from time to time that security really is a journey and not a destination!