Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: Adobe

Shockingly insecure

Yes I know, it’s a sensationalist headline, but you have to agree, any software component that comes out with 18 CVE numbers at once, is anything but secure.

Adobe have had a bad record when it comes to providing secure software and add-ons. The almost weekly Adobe 0-day exploits in Acrobat (reader) and Flash have now been joined by a list of critical vulnerabilities in Adobe’s Shockwave Player (11.5.6.606 and older). I’ve given a full list of the CVEs patched at the end of this post (see links). Currently these CVEs are reserved and don’t provide a great deal of information. However the Adobe advisory gives some interesting information about the flaws.

  • This update resolves a boundary error vulnerability that if exploited, could lead to memory corruption and possible code execution (CVE-2010-0127)
  • This update resolves a signedness error vulnerability that could lead to code execution (CVE-2010-0128)
  • This update resolves multiple memory corruption vulnerabilities due to integer overflow that could lead to code execution (CVE-2010-0129)
  • This update resolves an integer overflow vulnerability that could lead to code execution (CVE-2010-0130)
  • This update resolves a memory corruption vulnerability that could lead to code execution (CVE-2010-0986)
  • This update resolves a buffer overflow vulnerability that could lead to code execution (CVE-2010-0987)
  • This update resolves multiple memory corruption vulnerabilities that could lead to code execution (CVE-2010-1280)
  • This update resolves a memory corruption vulnerability that could lead to code execution (CVE-2010-1281)
  • This update resolves an infinite loop vulnerability that could lead to a denial of service (CVE-2010-1282)
  • This update resolves a memory corruption vulnerability that could lead to code execution (CVE-2010-1283)
  • This update resolves multiple memory corruption vulnerabilities that could lead to code execution (CVE-2010-1284)
  • This update resolves a memory corruption vulnerability that could lead to code execution (CVE-2010-1286)
  • This update resolves a memory corruption vulnerability that could lead to code execution (CVE-2010-1287)
  • This update resolves a buffer overflow vulnerability that could lead to code execution (CVE-2010-1288)
  • This update resolves a memory corruption vulnerability that could lead to code execution (CVE-2010-1289)
  • This update resolves a memory corruption vulnerability that could lead to code execution (CVE-2010-1290)
  • This update resolves a memory corruption vulnerability that could lead to code execution (CVE-2010-1291)
  • This update resolves a memory corruption vulnerability that could lead to code execution (CVE-2010-1292)

As you can see there’s a whole lot of “code execution” in this advisory. Adobe have, obviously, suggested an upgrade to the latest version (11.5.7.609) which deals with these issues. That’s one option obviously, the other, is to remove/disable  Shockwave Player. If you’re a home user, this is simple to achieve. Simple uninstall the software. However for enterprise users it’s a little harder to achieve. Below is one method to disable the Shockwave Player within Internet Explorer, and reduce the overall attack surface.

* Disclaimer * Please backup your configuration before performing any registry changes, and test this solution within your environment before using it.

Workaround:

To disable the Shockwave Player within Internet Explorer, you will need to edit the registry to add/alter a key within the “ActiveX Compatibility” subkey.

The exact location is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility

From here check to see if a Class identifier (CLSID) of {166B1BCA-3F9C-11CF-8075-444553540000} is already present. If not, create it and New DWORD called Compatibility Flags. Double click this DWORD and set th value of 0x400 (hex). That’s it, simply restart Internet Explorer and goto http://www.adobe.com/shockwave/welcome/to test.

Shockwave Player - Enabled

Shockwave Player - Disabled

 To make it a little easier, here’s the exported registry (.reg) file that you can directly import into your registry (please backup/test before rolling out).

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{166B1BCA-3F9C-11CF-8075-444553540000}]
"Compatibility Flags"=dword:00000400

You can also download a copy of the .reg file from here.

Links:

Advertisements

26C3: Defending the poor

Not sure how I managed to miss this on the first look at the schedule, but I almost missed this one. FX usually talks about IOS, but this time he’s turning his focus on Flash applications, and how to defend them. Certainly a turn-up for the books 😉 Fx’s first talk concentrating on pure defense. Nick Farr pulled off a pretty passable standup comedy act before the talk. There’s a career in show biz for him somewhere I’m sure 😉

Defending the poor: Countering Flash Exploits

Research was motivated by the BSI project (in late 2008) that reviewed the current state of Rich Internet Applications. Flash was shown to be lagging behind in regards to security, and no easy solution could be found. So how do we solve the problems ?

Who cares about flash security ?

  • People who don’t want to get owned when surfing pr0n
  • Apple user running PowerPc (no more updates)
  • Website operators (Flash adverts, …)

The common link between RIA environments (Flash, Silverlight/moonlight, JavaFX) is the plug-in based implementation. The majority of systems run flash, with Siverlight a long long long distant second.

The Flash security model

Primarily relies on the virtual machine runtime environment for sealing off access from the RIA code to the native machine. Permission decisions are based on so-called sandboxes. Generally Flash code can access local or remote resources, but should be restricted to one or the other.

Security Focus lists about 40 Flash vulnerabilities for the Flash player.

Attacks using Flash

Other than memory corruption and client-side attacks, Flash is used for a range of other attacks :

  • Flash has been used to perform DNS rebinding
  • targeting exploits by using Flash to perform client-side enumeration
  • Clickjacking style attacks
  • Sending additional HTTP headers (UPNP, CSRF Attacks)
  • Appending HTML/JavaScript to Flash files
  • Forwarding users / redirection (most commonly seen)

Flash Malware examples

  • SWF .AdJack/Gnida
  • CVE 2007-0071 Exploit
  • SWF/TrojanDownloader
  • ….

AV scanners appear to have issues detecting these threats if the malware is uncompressed. This could mean that AV scanners are not detecting the actual malware, but only packed strings or the packer itself.

Adobe Virtual Machines

The flash player actually contains 2 virtual machines
AVM1 is a historically grown weakly typed stack machine with support for object orientated code
AVM2 is a ECMA-262 (JavaScript) stack machine with a couple of modifications to increase strangeness. Programmed in ActionScript 3.

History of AVM1

  • First Scripting appears in SWF 3
  • SWF 4 introduces the AVM
  • SWF 5 introduces typed variables on the stack
  • SWF 6 fixes SWF 5
  • SWF 7 brings more OOP – Finally introduced exception handling !
  • SWF 8 never happened
  • SWF 9 already brings the AVM2 into the format
  • SWF 10 current

The whole thing is backwards compatible. Many security tools do not check ALL the code, and concentrate on the DoAction tags.

Desgin Weaknesses in AVM1
The byte offset in branch instructions allow for:

  • jumps into the middle of other instructions
  • jumping outside of code blocks

The order of code execution appears to be non-deterministic

  • Depends on a number of variables including how far an object it on the y axis !

Comparison to AVM2

  • Designed to make everything better
  • Spec not been updated since 2007
  • The “reference implementation” called Tamarin is not open-source
  • Format specification uses 30bit length fields to prevent integer overflows

Considerations for the defense approach

There are two main attack types to defend against

  • Malformed SWF files that cause memory corruption
  • Well formed SWF files that use the player API for evilness

Instrumentation of the player is bound to fail
Nobody wants to write a new flash player from the ground up

Solution – Normalization through Recreation

  • Safely parsing the complete SWF file, strictly checking the standards
  • ….

A Flash File Parser (coded in c# to allow for .Net and mono support) –> Blitzableiter

This will protect against possible malformed attacks, but not against SWF files performing simple redirections. In order to protect against this, you can use emulation to interpret the actions. This however is flawed, as the Flash player isn’t easy to predict, and the emulation could take a different direction to the player.

By performing runtime analysis, you can (for example) ensure that the same origin checks are imposed on functions that could result in the browser being forwarded (i.e ActionGetURL2). By patching the code, you can then open the SWF in the player without worrying about the user being forwarded to another site without warning.

This solution is trivial, but needs to be done as the Flash player doesn’t do these checks.

Blitzableiter

  • Features a full AVM1 assembler
  • Supports all 100 documented AVM1 instructions
  • Support for variable name
  • AVM2 not yet supported

In testing 82% of the test set ran correctly once being run through the engine. However the code inflation is currently at 224% of the original, which needs to get fixed. Timings are roughly 1 second additional wait for the whole process.

There is still work to be done to fix issues with some Flash compilers output (youtube is an example).

The tool can’t do anything about (yet) :

  • Heap Spraying
  • Flash API overflows

The Blitzableiter tool is open-source allowing others to check the code and find bugs. It will also allow others to integrate the features (into web browser extensions, Proxy filters, or file upload filters). Also so that Flash developers can test their own code. The code has been released under the GPLv3.

* Note: These are my notes from the talk. As always, it’s not possible to get every piece of fine detail. I’d suggest catching the video as soon as it’s made available.