Not sure how I managed to miss this on the first look at the schedule, but I almost missed this one. FX usually talks about IOS, but this time he’s turning his focus on Flash applications, and how to defend them. Certainly a turn-up for the books 😉 Fx’s first talk concentrating on pure defense. Nick Farr pulled off a pretty passable standup comedy act before the talk. There’s a career in show biz for him somewhere I’m sure 😉
Defending the poor: Countering Flash Exploits
Research was motivated by the BSI project (in late 2008) that reviewed the current state of Rich Internet Applications. Flash was shown to be lagging behind in regards to security, and no easy solution could be found. So how do we solve the problems ?
Who cares about flash security ?
- People who don’t want to get owned when surfing pr0n
- Apple user running PowerPc (no more updates)
- Website operators (Flash adverts, …)
The common link between RIA environments (Flash, Silverlight/moonlight, JavaFX) is the plug-in based implementation. The majority of systems run flash, with Siverlight a long long long distant second.
The Flash security model
Primarily relies on the virtual machine runtime environment for sealing off access from the RIA code to the native machine. Permission decisions are based on so-called sandboxes. Generally Flash code can access local or remote resources, but should be restricted to one or the other.
Security Focus lists about 40 Flash vulnerabilities for the Flash player.
Attacks using Flash
Other than memory corruption and client-side attacks, Flash is used for a range of other attacks :
- Flash has been used to perform DNS rebinding
- targeting exploits by using Flash to perform client-side enumeration
- Clickjacking style attacks
- Sending additional HTTP headers (UPNP, CSRF Attacks)
- Appending HTML/JavaScript to Flash files
- Forwarding users / redirection (most commonly seen)
Flash Malware examples
- SWF .AdJack/Gnida
- CVE 2007-0071 Exploit
- SWF/TrojanDownloader
- ….
AV scanners appear to have issues detecting these threats if the malware is uncompressed. This could mean that AV scanners are not detecting the actual malware, but only packed strings or the packer itself.
Adobe Virtual Machines
The flash player actually contains 2 virtual machines
AVM1 is a historically grown weakly typed stack machine with support for object orientated code
AVM2 is a ECMA-262 (JavaScript) stack machine with a couple of modifications to increase strangeness. Programmed in ActionScript 3.
History of AVM1
- First Scripting appears in SWF 3
- SWF 4 introduces the AVM
- SWF 5 introduces typed variables on the stack
- SWF 6 fixes SWF 5
- SWF 7 brings more OOP – Finally introduced exception handling !
- SWF 8 never happened
- SWF 9 already brings the AVM2 into the format
- SWF 10 current
The whole thing is backwards compatible. Many security tools do not check ALL the code, and concentrate on the DoAction tags.
Desgin Weaknesses in AVM1
The byte offset in branch instructions allow for:
- jumps into the middle of other instructions
- jumping outside of code blocks
The order of code execution appears to be non-deterministic
- Depends on a number of variables including how far an object it on the y axis !
Comparison to AVM2
- Designed to make everything better
- Spec not been updated since 2007
- The “reference implementation” called Tamarin is not open-source
- Format specification uses 30bit length fields to prevent integer overflows
Considerations for the defense approach
There are two main attack types to defend against
- Malformed SWF files that cause memory corruption
- Well formed SWF files that use the player API for evilness
Instrumentation of the player is bound to fail
Nobody wants to write a new flash player from the ground up
Solution – Normalization through Recreation
- Safely parsing the complete SWF file, strictly checking the standards
- ….
A Flash File Parser (coded in c# to allow for .Net and mono support) –> Blitzableiter
This will protect against possible malformed attacks, but not against SWF files performing simple redirections. In order to protect against this, you can use emulation to interpret the actions. This however is flawed, as the Flash player isn’t easy to predict, and the emulation could take a different direction to the player.
By performing runtime analysis, you can (for example) ensure that the same origin checks are imposed on functions that could result in the browser being forwarded (i.e ActionGetURL2). By patching the code, you can then open the SWF in the player without worrying about the user being forwarded to another site without warning.
This solution is trivial, but needs to be done as the Flash player doesn’t do these checks.
Blitzableiter
- Features a full AVM1 assembler
- Supports all 100 documented AVM1 instructions
- Support for variable name
- AVM2 not yet supported
In testing 82% of the test set ran correctly once being run through the engine. However the code inflation is currently at 224% of the original, which needs to get fixed. Timings are roughly 1 second additional wait for the whole process.
There is still work to be done to fix issues with some Flash compilers output (youtube is an example).
The tool can’t do anything about (yet) :
- Heap Spraying
- Flash API overflows
The Blitzableiter tool is open-source allowing others to check the code and find bugs. It will also allow others to integrate the features (into web browser extensions, Proxy filters, or file upload filters). Also so that Flash developers can test their own code. The code has been released under the GPLv3.
* Note: These are my notes from the talk. As always, it’s not possible to get every piece of fine detail. I’d suggest catching the video as soon as it’s made available.
Cатсн²² (in)sесuяitу / ChrisJohnRiley 