From

Thank you

Sorry

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 Google, published on his personal blog a way to get around Flash Player's local-within-filesystem sandbox.

[ Windows 7 is making huge inroads into business IT. But with it comes new security threats and security methods. InfoWorld's expert contributors show you how to secure the new OS in the "Windows 7 Security Deep Dive" PDF guide. ]

[ Build and deploy an effective line of defense against corporate intruders with InfoWorld's Encryption Deep Dive PDF expert guide. Download it today! | Stay up to date on the latest security developments with InfoWorld's Security newsletter. ]

The sandbox allows a SWF (Shockwave Flash) 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.