Skip to content

Latest commit

 

History

History
66 lines (65 loc) · 14 KB

issue.md

File metadata and controls

66 lines (65 loc) · 14 KB
Raw

Adobe Flash Player SOP bypass a.k.a. "same-site flashing via JPG file"
Jakub Kaluzny


Recently I have been pentesting a web application, which utilised one of popular SWF libraries. It turned out that few really low risk issues can result in a tricky XSS when combined together. The attack wouldn't be normally possible due to Same Origin Policy guaranteed by Adobe Flash but in specific circumstances it is possible to abuse it.

The Loader.load() problem

Some SWF libraries need to import more SWF libraries. Some of them do it dynamically by providing a path to the library, which is not really the best practice but it is not that bad thanks to SOP. Most of the libraries use standard Loader.load() method, which accepts multiple mime types as parameter. You can load JPG file and you can load SWF file as well. SWF file does not need to be a movie, it can be ActionScript executable code. Let's suppose our target website has a following flash embedded:

http://target/lib.swf?dependency=lib2.swf

And it loads the dependency using a standard ActionScript mechanism:

loader:Loader = new Loader() ; loader.load(dependency); addChild(loader);

If there is no validation on dependency parameter, the attacker may try to craft the following URL:

http://targ.et/lib.swf?dependency=http://malicious/exploit.swf

What will happen? If the exploit.swf is a simple movie file (no AS, just image/video), we just found a Cross-Site-Flashing (XSF) vulnerability, which could only result in reputation loss risk (e.g. displaying arbitrary movie content on the target website, maybe some phishing).

What will happen if exploit.swf contains some ActionScript code which tries to access cookies? Simply it won't succeed - Same Origin Policy mechanism will stop the browser from executing the code.

Let's combine it with file upload vulnerabilities

If we were able to upload arbitrary SWF file to the target server, we would be able to access user cookies anyways, which has nothing to do with Loader design principles. But what if we are able to upload an arbitrary JPG file to the server with the contents of SWF exploit?

http://target/upload/malicious.jpg
- does not pose a threat itself, as it is transferred with JPEG mime type, as an image.

But now, opening the following URL

http://target/lib.swf?dependency=upload/malicious.jpg
allows to execute arbitrary JS code in the target context - basically, Cross-Site Scripting (XSS).

Remediation

Basically, breaking the attack chain requires at least one of the following:

  • [end-client] patching web application to not allow uploading arbitrary SWF files with other (JPG) extensions
  • [end-client] introducing restrictions on parameters to lib.swf (web server level)
  • [SWF library vendor] restricting loading external SWF files in SWF library
  • [SWF library vendor] restricting loading files with extension other than SWF
  • [Adobe] do not allow importing ActionScript SWFs with extension other than .swf
  • [Adobe] Automatically set LoaderContext.allowCodeImport = false on non-SWF files

Adobe does not recognise this issue as a vulnerability, as there are ways mentioned in docs to mitigate it (e.g. setting LoaderContext.allowCodeImport = false). However, this setting is more like security opt-in, not following "secure by design" principle.

Summary

If you find:

  • SWF library vulnerable to XSF (or actually - same-site flashing)

and

  • you can upload SWF files with JPG extension on the server

It is most likely vulnerable to XSS. You can find PoC exploit in this directory (description in README.md)