Adobe Flash Multiple Vulnerabilities

2008-11-24 / 2008-11-25
Credit: iSEC Partners
Risk: Low
Local: No
Remote: Yes
CWE: CWE-399

iSEC Partners Security Advisory - 2008-01-flash -------------------------------------------- Adobe Flash Multiple Vulnerabilities Vendor: Adobe, Inc. Vendor URL: Versions affected: Flash Player 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: Vendor Advisory URL: 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 and earlier versions upgrade to the newest version 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. info_at_isecpartners&#46;com


Vote for this issue:


Thanks for you vote!


Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.

(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024,


Back to Top