CVE-2016-4271


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[1].

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.

Similarly, the local-with-filesystem sandbox (which can be chosen when compiling your ActionScript code), has been designed to keep remote hosts away from local files, but it’s designed in the opposite way: the SWF can access every file on the local filesystem but it can’t access remote networks. Keep in mind that this feature can’t be enabled on Javascript in any way – Javascript is “stuck” in a sandbox that is more similar to local-with-networking.

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.

As previously said, SWFs in local-with-filesystem sandbox can’t «communicate with the network in any way». In an HTML document, SWF is surrounded by other technologies that aren’t bind to that principle: just think about Javascript. The real issue behind every vulnerability reported in this article is that it’s really difficult to make sure that Javascript (which can communicate with remote networks) won’t be able to read a single bit of what Flash is reading.

To sum up, when we are using file: URI scheme:

  • Flash can access local filesystem
  • Javascript can send data to remote hosts

It’s obvious that the only thing between the attacker and user’s local files is the fact that Javascript can’t communicate with Flash in any way. Flash tries to block every dangerous feature that may leak information to Javascript, but it fails to do it correctly with navigateToURL().

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[2].

In Practice – Why it didn’t work.

  • A) navigateToURL() – local sandbox bypass via URI percent-encoding[3]

Don’t trust percentages. 100% sure. 

As previously said, navigateToURL() method can be used, even if the SWF is in local-with-filesystem sandbox. Obviously, if we try to get files on remote networks a security exception will be returned, but it can surely be used to reach local files. Due to the fact that Javascript can access information contained in the URL, navigateToURL() is the perfect way to communicate data from Flash to Javascript (and then, remote hosts). At the time of the discovery, Adobe Flash was performing a lot of sanitizations on URIs (e.g to get rid of multiple slashes, changing backslashes to forwardslashes, etc.) but it ignored percent-encoding. Let’s see how it’s possible to abuse this behaviour:

Following RFC 3986, 2.1, this URI

can be also requested as

Despite the fact that both of them are valid, they’re not the same thing. Javascript in Mozilla Firefox and Safari can detect the difference by simply reading document.URL. In this way, Flash is communicating with Javascript : we can now bypass local-with-filesystem sandbox and reach external networks. This concept is used in the following PoC to steal a credit card number.

  • Proof of Concept

To make everything funnier, I’ve created a PoC exploit which is both a valid HTML and a SWF file.
It looks pretty good in VIM:

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[4]

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

As you can see, there are spaces at the end of the URI, and even in this case, its behaviour makes Flash able to exchange data with Javascript, violating local-with-filesystem sandbox. In fact, Javascript can detect the difference between the first and the second URI, giving Flash the opportunity to pass a little amount of data per each navigateToURL() call. In this case, the mitigation warning dialog that we’ve talked about before seems to strongly limit the impact of this issue since we need to perform multiple navigateToURL() calls to pass a similar amount of data of the issue A). At a first glance, this vulnerability seems to be unusable in a real world scenario.
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.

In the following link you can find an Exploit PoC that uses the vulnerability in paragraph B) and the lack of Clickjacking protection to extract credit card data in Google Chrome, while the victim is playing a (really boring) Javascript game.

  • 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.

– @lpontorieri

 

 

 


Disclosure Timeline:


[1] In this article we will focus on local-with-filesystem and local-with-networking sandboxes. For more information, visit adobe.com

[2] 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.

[3] Vulnerability was confirmed on Mozilla Firefox and Safari.

[4] Issue confirmed on Google Chrome, Mozilla Firefox and Opera running on Windows OS.

One thought on “Flash sandbox bypass: local data exfiltration

Comments are closed.