It doesn't take much searching before I come across Mark Dowd's pioneering Leveraging the ActionScript Virtual Machine paper. It uses exactly this problem as an example. I can remember the excitement in the security community when this exploit was published, but I can't quite remember what it was all about. "Can I use the computer?" comes a voice from behind me. "Just a minute! I just need to finish up. I'm almost done."
Back to Dowd's Flash exploit. Adobe's Flash implementation uses
SceneCount to reserve memory. To prevent any mischief, it carries out some verification before doing so. But in doing so, Adobe uses a signed "greater than" comparison. And because the highest bit – the 'sign bit' – of the
0x84039a19 is set, this yields a negative value.
As a result, the check doesn't do what it's supposed to and the Flash interpreter tries to reserve memory with the value from
SceneCount – which of course fails. The program, however, does not realise this and uses the null pointer, intended to indicate an error, anyway. Boom!
But it's not quite as simple as all that. For a long time it was thought that this kind of bug would simply cause the program to crash and could not be exploited to execute injected code in a controlled manner. Mark Dowd used this example to show that it is indeed possible. Highly simplified, it works like this: a little later, the Flash interpreter writes a value which can be selected by the attacker to the address
0+SceneCount. By using a suitable value for
SceneCount coupled with the malformed Action Script byte stream, the attacker can overwrite an address pointer for a jump or call instruction such that his injected code is activated.
Normal stability tests will rarely detect this kind of security problem. The developer is in a similar position to that of an engineer calculating the load-bearing capacity of a bridge. The engineer determines that the bridge should easily be able to take one hundred people, but neglects to consider that 100 marching soldiers, will march over the bridge in step and hit the bridge's resonant frequency. The vibration is steadily amplified until the bridge collapses. Resonance disasters like this did in fact cause the collapse of two bridges in France and England in the 19th century, with significant loss of life.
In fact software developers have it even harder – they have to assume that the bad guys will deliberately jump up-and-down, adjusting their rhythm until they find the critical frequency. Then they'll go on doing it until the bridge collapses – or, to return to reality, until their manipulated movie clip causes a remote code execution.
Talking of code reminds me of the
DEFINEBITSJPEG tag, which contains the reference to urlmon.dll, the URL and the strange file name.