[As ever, you can read this on the BBC News website]
I used to be a professional computer programmer, writing in the C language on the Unix operating system back in the 1980’s when half a megabyte of memory was enough to support a sixteen-user system.
These days I’m only really up to hacking other people’s code to meet my needs, although I do occasionally find myself messing around with languages like PHP and JavaScript and I’m tempted to learn Python.
But I’m still enough of a coder to share the excitement that has been rippling through the IT security community recently after the publication of a paper from Mark Dowd, X-Force Researcher at IBM Internet Security Systems.
‘Application-Specific Attacks: Leveraging the ActionScript Virtual Machine’ may not be up with ‘Fear and Loathing in Las Vegas’ in the great titles of publishing history, but its impact on the way hackers, criminals and malicious kids find their way into our computers may well be as great as Hunter S Thompson’s on the practice of journalism.
And it could end up costing a lot of people a lot of money as they fight back against a new wave of viruses, trojans, keyloggers and other malware built using the techniques he outlines, although of course that isn’t Dowd’s goal in publishing the paper.
In fact he has done us all a massive service by alerting programmers and software publishers to a way of attacking a running computer program that was thought unworkable. He has also performed an act of intellectual bravado that prompted Thomas Ptacek at Matasanto to claim ‘Mark Dowd was, in fact, sent back through time to kill the mother of the person who will grow up to challenge SkyNet’ – a reference to the Terminator as played by Arnold Schwarzenegger.
So what’s the excitement about?
The paper describes how to attack a particular component in Adobe’s Flash player, used by millions of us every day to display multimedia content in web pages and elsewhere.
It’s a complex, multistage attack that begins with two separate bugs. First, when Flash reads in a file to play it checks all of the data carefully. One of the numbers it reads tells the Flash player how much memory it will need for the movie. This number is checked as if it can be either positive or negative, but when it is read it is treated as if it is always positive, and this is the first bug.
Since every number in a computer is held as a pattern of 1 and 0, this allows Dowd to create a Flash movie that seems to have a small and sensible memory requirement but actually asks for far more RAM than any computer could offer.
Normally this would make the program crash, but the Flash player fails to check whether the function that goes and gets the memory, called ‘malloc()’, was successful and just assumes it was. This is the second bug, and it opens up the system since instead of being given a chunk of memory – or rather being told the address where which the memory available can be found – Flash gets what is known as a ‘NULL’ pointer, an address that doesn’t point anywhere.
Until now attacks using these NULL pointers were thought to be too complicated to be any real threat, but Dowd has figured out how to take this NULL pointer and use it to write data of his choosing into a known location of the computer’s memory, from where it is read by another component of the Flash player, the ActionScript Virtual Machine.
And from there he can, having solved a series of computational challenges that are equivalent to doing multi-dimensional Soduku while waterskiing, own your computer by getting the ActionScript Virtual Machine to run his commands without realising it.
It works for the Flash player on Firefox or Internet Explorer. It even works on Vista because Flash doesn’t take advantage of the extra memory protection measures that Vista offers.
And as I understand it, and although I used to be a professional programmer and so could follow the complexities of the paper I may well have missed or misunderstood some aspects of it so appeal to the wisdom of the crowd to let me know if I’ve got it wrong, it isn’t restricted to Flash, either: Dowd’s paper describes a whole new technique for exploiting security flaws in software with virtual machines like the ActionScript one.
Or, rather, it turns a whole set of common programming techniques into potential security flaws. This is comparable to the 1996 discovery by the hacker Aleph One that it is possible to take advantage of programs that fail to check whether the data they read is too big for the storage allocated to it and persuade them to start running a program written by the attacker.
These ‘buffer overflow’ attacks still account for many of the security problems in today’s code, even though the issue has been known about for twelve years.
We haven’t yet seen any public exploits based on Mark Dowd’s research, but it is only a matter of time. Programs that use virtual machines are increasingly common, and those trying to craft the exploits now know where to look for vulnerabilities. As you might expect, Flash has been patched already, so the elegant attack described in the paper will no longer work.
The Bank of England is in the process of handing out £50 billion to UK banks to help them cope with a liquidity problem that has resulted from the collapse of the ‘sub-prime’ mortgage market in the USA and the failure of the many sophisticated financial instruments built on top of those loans. We will feel the impact of that collapse for many years, often in unexpected areas.
Mark Dowd’s remarkable work has just pulled the carpet out of the programming world in a similar way, and its impact is also going to be felt for a very long time.
If nothing else it should increase the pressure on software developers to use more formal and structured development methods so that coders do not leave exploitable functions in their code. Sadly, as we’ve seen with the constant stream of buffer overflow bugs that emerge even today, it’s unlikely that people will take sufficient care, and we’re likely to see a lot of exploits emerge over the next few years.
Perhaps we should allow those affected by this technique to sue their developers for exemplary damages since there is now no excuse for not checking and fixing vulnerable code?
Bill’s Links