Flash sandbox bypass: local data exfiltration
End of the love story between flash and local files
13 September 2016, Adobe kills the local-with-filesystem sandbox
Like a lot of love stories, the one between Flash and local files is over. Local-with-filesystem sandbox has today, after a decade, been killed by Adobe, making (almost) obsolete those Flash files using that feature.
Before we start explaining why on earth you should care about this policy change and why this is a huge leap forward in Adobe Flash Security, we need to explain what local-with-filesystem sandbox is and how modern web browsers handle local files. If you’re an impatient guy and want to go ahead to the PoC, you can go directly to the paragraph “In Practice – Why it didn’t work”.
What is local-with-filesystem sandbox and why on Earth should I care about it?
If you had the pleasure of starting ActionScript programming and if you’re not one of those developer that read only the odd pages of the documentation, you should have heard about Adobe Flash Security Sandboxes (luckily for me it was on page 53).
In simple terms, Security Sandboxes control which external resources can be loaded by a SWF. The most famous one is the “Remote Security Sandbox” whose task is to identify which files can be loaded by a Flash file located on a remote host: you encountered it every time you loaded a SWF via HTTP. Instead, when a flash file is loaded on file:// URI scheme, SWF files are placed in one of the following Security Sandboxes: local-with-filesystem, local-with-networking, local-trusted or the AIR application sandbox.
The local-with-networking sandbox is the most common (and the default) one: it forbids Flash files to load resources on the local filesystem.
This behaviour serves the security purpose to keep local files away from remote hosts. In this way your romantic rivals won’t be able to steal pictures of your girlfriend saved on your desktop, but even more importantly it prevents NSA agents bad guys, from access your private documents, passwords, credit card information… and pictures of your girlfriend on your desktop.
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.” – adobe.com
Now it’s time to answer the question “Why on Earth should I care about it?”: well, simply, this security approach didn’t work properly… and it didn’t for a long time.
In Theory – Why it should work but it doesn’t.
In theory, that security model was good. In practice, it was too hard to deploy correctly. And that’s why Adobe chose to get (almost) rid of that sandbox.
To sum up, when we are using file: URI scheme:
- Flash can access local filesystem
In the next paragraph we’ll talk about 3 different (but linked to each other) issues, which can be exploited to extract data from local filesystem. The first two take advantage of the web browsers RFC 3986 implementation (Uniform Resource Identifier: Generic Syntax) to pass a malicious argument to navigateToURL() and extract data from local files. The last one, designed to work on Google Chrome, shows how an old enemy like Clickjacking can be used against Flash to exploit these vulnerabilities in the wild, despite the mitigation.
In Practice – Why it didn’t work.
- A) navigateToURL() – local sandbox bypass via URI percent-encoding
Don’t trust percentages. 100% sure.
Following RFC 3986, 2.1, this URI
can be also requested as
- Proof of Concept
You can download it here: Fun With Percent Encoding.
Let’s see it in action:
Video – How it felt before the mitigation
Video – After the mitigation
- B) navigateToURL() – Abusing whitespaces to bypass local sandbox
Can you see me?
Similarly to the issue described in the previous paragraph, a little known feature of local URIs on Windows systems is ignored by navigateToURL(). This URI
Can be also requested as
In the next paragraph, we’re trying to discredit this last statement, in order to prove once again how mitigations aren’t a good answer to security holes.
- C) Adobe Flash – Clickjacking against navigateToURL() warning dialog
So, my old enemy, we meet again!
Adobe Flash has been the favourite target of Clickjacking attacks since the very first moment of the spread of that issue. Ironically, the same kind of attack can be used against Adobe’s navigateToURL() issues mitigation on Google Chrome.
- Proof of Concept
You can download it here: Pull ups With Mr. Sandy Box.
Let’s see it how it worked:
Is Adobe Flash still vulnerable? Is it fixed?
Yes but No. Flash has never fixed these issues and local-with-filesystem sandbox can be optionally enabled, by editing a configuration file. So, Flash still contains the vulnerable piece of code, but it can be exploited only if an uncommon setting is enabled. In this way, these vulnerabilities are “frozen” in the code and their fate is to be reproduced in every future version of Adobe Flash, but it seems unrealistic to use those again in a real world scenario.
At least, for now.
04/04/2015: Vulnerabilities reported to Adobe PSIRT.
06/04/2015: Adobe acknowledges the report and assigns an identification number (PSIRT-3562).
17/04/2015: Contacted Adobe for updates, no response.
23/04/2015: Contacted Adobe again, no reply.
29/04/2015: Contacted again: Adobe replies they're still working on the report.
20/06/2015: CVE ids request sent.
23/06/2015: Adobe replies that vulnerabilities A) and B) won't be fixed (because of the warning dialog mitigation). They started working with Google on C).
09/09/2016: Adobe PSIRT forewarns they'll change their security sandbox policy in next Flash update.
26/09/2016: Vulnerabilities published.
 Some time ago, vulnerabilities here described were mitigated by a warning dialog, and now they are (almost) inoffensive because of the last Flash update. That warning dialog asks for authorization to “Connect to the internet” (this sentence is incorrect and misleading: in the local-with-filesystem sandbox, we can’t access remote hosts) and is triggered by every navigateToURL() call.
 Vulnerability was confirmed on Mozilla Firefox and Safari.
 Issue confirmed on Google Chrome, Mozilla Firefox and Opera running on Windows OS.