Security researcher finds way around Flash sandbox

Adobe has tightened up Flash but a researcher has found a way to send data to a remote server

A security researcher has found a gap in the way Adobe Systems has fortified its Flash Player for better security, which could result in data being stolen and sent to a remote server.

Billy Rios, a researcher who is a security engineer for Microsoft, published on his personal blog a way to get around Flash Player's local-within-filesystem sandbox.

The sandbox allows a Shockwave Flash (SWF) file to read local files but not send data over the network. It also prevents SWF files from making JavaScript calls or HTTP or HTTPS requests, Rios wrote.

A local file is described as one that can be referenced using "file: protocol" or a Universal Naming Convention path, Rios wrote.

But Rios found that the sandbox restrictions are actually not quite so strict. He found he could bypass the sandbox but reformatting the request, such as "file://request to a remote server." Adobe, however, limits those requests to local IP (Internet protocol) addresses and hostnames, Rios wrote.

Adobe also blacklists some protocol handlers but not all, a method that Rios considers dangerous.

"If we can find a protocol handler that hasn't been blacklisted by Adobe and allows for network communication, we win," Rios wrote.

Flash does not blacklist the "mhtml" protocol handler, which is part of Microsoft's Outlook Express application and installed on Windows systems. So a SWF file could export data by using a command, which Rios detailed in his blog.

Rios said the method is particularly effective since if the request fails, the data will still be transmitted to the attacker's server without the victim knowing.

Rios wrote that there are two lessons to be learned: First, running untrusted SWF code is dangerous and that protocol handler blacklists "are bad."

An Adobe spokeswoman said the company has reviewed Rios' blog post and logged a bug, classifying it as a "moderate" risk according to its Adobe Severity Rating System.

"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," she wrote in an e-mail. "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."

Adobe and Google worked together on the security improvements in Flash. Last month, the two companies released to developers the first version of Flash that uses a sandbox. It works on Google's Chrome browser on the Windows XP, Vista and 7 operating systems.

The release is a continuation of a broad program by Adobe to improve the security of its products, which includes the introduction of a regular patching cycle timed with Microsoft's Patch Tuesday releases.

Adobe also uses a sandbox in its Reader X product, which was released in November. Reader's sandbox seals the application off from attacks designed to tamper with, for example, a computer's file system or registry. The sandbox interacts with the file system, but those communications go through a broker, which limits particular actions.

Send news tips and comments to jeremy_kirk@idg.com

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags Adobe Systems

More about Adobe SystemsAdobe SystemsetworkGoogleMicrosoft

Show Comments
[]