Adobe Flash Multiple Vulnerabilities
iSEC Partners Security Advisory - 2008-01-flash
--------------------------------------------
Adobe Flash Multiple Vulnerabilities
Vendor: Adobe, Inc.
Vendor URL: http://www.adobe.com
Versions affected: Flash Player 9.0.124.0 and earlier,
AIR 1.1, Flash CS4 Professional, Flash CS3 Professional, Flex 3
Systems Affected: All platforms
Severity: High - potential code execution
Author: Riley Hassell <riley[at]isecpartners[dot]com>
Vendor notified: 2008-07-22
Public release: 2008-11-21
Advisory URL: https://www.isecpartners.com/advisories/2008-01-flash.txt
Vendor Advisory URL:
http://www.adobe.com/support/security/bulletins/apsb08-22.html
Summary:
--------
iSEC applied targeted fuzzing to the ActionScript 2 virtual machine used
by the Adobe Flash player, and identified several issues which could
lead to denial of service, information disclosure or code execution
when parsing a malicious SWF file. The majority of testing occurred
during 120 hours of automated SWF-specific fault injection testing
in which several hundred unique control paths were identified that
trigger bugs and/or potential vulnerabilities in the Adobe Flash Player.
Paths leading to duplicate issues where condensed down to a number of
unique problems in the Adobe Flash Player. The primary cause for these
vulnerabilities appears to be simple failures in verifying the bounds of
compartmentalized structures.
Details:
--------
Of the reported issues, several could be used by an attacker to
partially or fully control object member pointers with addresses of
his or her choosing. This may result in write operations into the host
process' memory with data of the attacker's choosing, which is usually a
serious problem and could lead to code execution.
The majority of the issues discovered lead to a out of bounds read,
often caught by the operating system and converted into an error. For
example, in the affected versions of Flash player the following Action
Record (ActionScript 2.0) types failed to verify the size of member
elements (DefineConstantPool, ActionJump, ActionPush, ActionTry), as
well as several other Action Record types. These boundary issues become
apparent when Flash movies (.swf files consisting of a series of Action
Records or "tags") contain data with values for offsets which point to
regions beyond the end of the Flash file's memory.
When tried randomly, these read beyond bounds often hit an invalid
memory page, for example at the end of the Flash movie. Perhaps because
of this, out of bounds reads are, often incorrectly, considered harmless
by developers and testers. Unbounded reads which result in side effects
can still be used to expose sensitive information however. iSEC was
able to read sensitive data structures from process memory using this
technique. Since the Flash movie is located in an region of process
memory that is highly fragmented, the memory following our Flash movie
is often unavailable, and in its place is an invalid page. When this
page is encountered an exception will be thrown. Using the behavior of
the memory management system to guide us, we can reduce the size of the
movie buffer so that it no longer resides in highly fragmented memory
but instead in more interesting contiguous regions, such as a private
heap.
In the case of the DefineConstantPool record we were able supply an
arbitrary constant count. The player then parses constant values
(strings) from the string table, and continues reading null terminated
strings in the adjacent tag data, eventually reading from memory
adjacent to the Flash movie. References to these values are stored in
a table of constants that can be later accessed using a set of action
records. A proof of concept was developed and presented to the vendor
to demonstrate the threat of read beyond bounds issues to complex file
formats such as the SWF file format.
Finally, other issues were found that suggest the lack of validation
on the contents of the dictionary data structure. Elements in the
structure, e.g. "characters" are previously defined using a variety of
define operations. They are subsequent referenced by their "character
id" and inserted in the Flash player workspace. During the retrieval of
the character elements from the dictionary, they are not validated to
in fact exist, and often their structure is not validated prior to use.
This typically leads to a null pointer dereference and crash, which is
much less dangerous.
Fix Information:
----------------
All issues considered by Adobe to be critical are reported resolved in
current versions of the Flash Player and Adobe AIR. Adobe recommends
all users of Adobe Flash Player 9.0.124.0 and earlier versions upgrade
to the newest version 10.0.12.36 by downloading it from the Player
Download Center, or by using the auto-update mechanism within the
product when prompted.
Vendor Communication:
----------------
07/22/08 - Adobe PSIRT contacted and vulnerabilities disclosed
07/23/08 - Proof of Concept for memory corruption, null pointer issues provided
07/24/08 - Proof of Concept delivered for read beyond bounds issues provided
07/30/08 - Communication initiated for POC samples, PSIRT acknowledges
verification testing is underway
08/02/08 - PSIRT response to iSEC that patch release was set at hard date in
mid November and requested a stay of release until mid November
09/09/08 - PSIRT reports major issues have been remediated, but some issues
were declared safe because they only resulted in denial of service
11/17/08 - Vendor advisory released
11/21/08 - iSEC advisory released
Thanks to:
----------
The Adobe product security team for a timely response to this issue.
Josh Zelonis of iSEC for his assistance dissecting the SWF file format
and development of the SWF 010 Editor Template.
About iSEC Partners:
--------------------
iSEC Partners is a full-service security consulting firm that provides
penetration testing, secure systems development, security education and
software design verification, with offices in San Francisco, Seattle,
and Ewa Beach.
https://www.isecpartners.com
info@xxxxxxxxxxxxxxxx