On Monday, Adobe Systems rolled out its new Web 2.0 development tool, Adobe Integrated Runtime, or AIR. Following its release were some concerns from the security community.
Adobe CEO Shantanu Narayen talks up AIR at a San Francisco event.
(Credit: Charles Cooper/CNET News.com)AIR, formerly Adobe Apollo, is a runtime environment that allows developers use HTML, Flash, AJAX, Flex, and other Web 2.0 tools to create desktop applications. One such application built using Adobe AIR comes from Nickelodeon Online.
But some security experts are concerned about local file access by AIR applications. Recently, Firefox experienced a vulnerability that could have allowed remote attackers to access a targeted file system. To mitigate this, Adobe says it implemented a sandboxing environment, however, Adobe's documentation suggests that the sandboxes are less secure than a Web browser's sandbox.
Additionally, Adobe says that AIR applications need to be digitally signed, however, these certificates can be self-signed. And many users will ignore the warnings and run untrusted applications.
Finally, there is the potential for Cross-Site Scripting (XSS), SQL injection, and local link injection. While these threats are not limited to Adobe AIR, developers could gain a false sense of security by relying only on AIR's weaker sandbox protection.
Adobe has also provided the following: an informative article titled "Introduction to AIR security" and a white paper, "AIR Security" (PDF). But Lenny Zeltser, writing on the Sans Internet Storm Center site, notes that "many developers will be unaware of Adobe AIR security best practices or will knowingly take shortcuts that expose end users to attacks."
On Tuesday, exploits for the Yahoo apps were reported circulating. There is currently no patch from the individual vendors, so the only workaround is to disable the several specific, vulnerable ActiveX controls. (ActiveX controls were developed by Microsoft for use with Internet Explorer and other browsers.)
The SANS tool, available here, eliminates the risks associated with editing the Windows system registry file. A command line version is available here.
The kill-bit tool first checks your system to see if any of the vulnerable CLSIDs exist. If so, the tool saves a copy of any values currently set, then updates the display to show that the CLSID--the unique sequence assigned to each ActiveX component that specifies which control you are using--exists. It also shows whether the kill-bit flag is set. To set the kill-bit, just check the box beside any of the affected ActiveX controls then click on the "Set" button. Unchecking any of the boxes will either reset the "Compatibility Flags" to their saved value or remove the CLSID entirely (if you didn't have the control installed in the first place).
SANS suggests setting the kill-bits for all of the affected ActiveX controls, and, even if you don't currently have one or more of these CLSIDs installed on your machine, go ahead set the kill-bit for controls that might be added to your system in the future.
- prev
- 1
- next
