Bypassing Flash’s local-with-filesystem Sandbox Redux

By | December 12, 2011

I suppose I should explain what Adobe refers to as a security control bypass (CVE-2011-2429).  There exists a number of different security sandboxes that the Flash Player uses to restrict SWFs. In this case, I was able to create a SWF that bypassed the restrictions imposed by a local-with-filesystem sandbox.

“The local-with-filesystem sandbox–For security purposes, Flash Player places all local SWF files and assets in the local-with-file-system sandbox, by default. From this sandbox, SWF files can read local files (by using the URLLoader class, for example), but they cannot communicate with the network in any way. This assures the user that local data cannot be leaked out to the network or otherwise inappropriately shared.” [1]

Since a SWF placed into the local-with-filesystem sandbox can access local files, all we need to do is figure out a way to “communicate with the network in any way” in order to exfiltrate files off of a victim’s computer.  Billy Rios noticed that the getURL function was using protocol black-listing to prevent network communication with the outside world, therefore he used the mhtml psuedo URL scheme, which works in IE, earlier this year to bypass the security restrictions [2].  When I tried to reproduce his research, I received an annoying security exception from the Flash Player, so I searched for other pseudo URL schemes that might be useful, since I noticed that the Flash Player continued to simply black-list protocols as opposed to implementing some sort of white-list of acceptable protocols.  I quickly came across the view-source pseudo URL scheme that appeared to achieve similar results in Firefox and Chrome.  The view-source scheme is used to *gasp* view the source of a resource, and you’ll notice that both browsers will make a new HTTP request to retrieve the resource if the resource has not been cached yet.

The proof of concept is fairly simplistic, and there is technically a file size restriction on the files that can be extracted from the target’s machine due to browser restrictions on the URL length, but it might be possible to bypass this restriction by using custom HTTP headers to transfer the file contents instead, or using a different technique. The screenshot below shows the PoC SWF in action stealing some s3cr3t filez.

Moral of the story: black-listing URL schemes is still a bad idea.

[1] –

[2] –