1. Advisory Information
Title: XnView MBM Processing Heap Overflow
Advisory Id: CORE-2010-0514
Advisory URL: http://www.coresecurity.com/content/xnview-mbm-hea
Date published: 2010-06-14
Date of last update: 2010-06-14
Vendors contacted: XnView
Release mode: Coordinated release
2. Vulnerability Information
Class: Buffer overflow [CWE-119]
Impact: Code execution
Remotely Exploitable: Yes (client-side)
Locally Exploitable: No
CVE Name: N/A
Bugtraq ID: N/A
3. Vulnerability Description
XnView [1] is prone to a security vulnerability when processing MBM files. This vulnerability could be exploited by a remote attacker to execute arbitrary code on the target machine, by enticing the user of XnView to open a specially crafted file.
4. Vulnerable packages
- XnView 1.97.4
- Older versions are probably affected too, but they were not checked.
5. Non-vulnerable packages
- XnView 1.97.5
6. Vendor Information, Solutions and Workarounds
Update to the latest version of XnView, available on the website http://www.xnview.com/
7. Credits
This vulnerability was discovered by Mauro Olea and researched by Mauro Olea and Nahuel Riva from Core Security Technologies. Publication of this advisory was coordinated by Carlos Sarraute from Core Security Advisories team.
8. Technical Description / Proof of Concept Code
XnView is prone to a security vulnerability when processing MBM files. The version used in our tests in XnView 1.97.4 running on Windows 2000 SP4. By enticing the user of XnView to open a specially crafted file, a remote attacker may exploit this vulnerability to gain arbitrary code execution.
The MBM file format (shortened from MultiBitMap) is a container for a set of bitmap images. MBM files are used by most Symbian applications to store their graphical content. MBM files can be created with the BMCONV tool which is supplied with any Symbian (and EPOC) SDK.
8.1. First Proof-of-Concept
An MBM file that triggers this vulnerability is available at [2]. The following is an excerpt of the vulnerable code, and the value of the registers when the vulnerability is triggered (the value of EAX and ECX are controlled by the attacker).
[+ full code]8.2. Second Proof-of-Concept
By generating a second malformed .MBM file (available at [2]), we can trigger a heap overflow that may lead to arbitrary code execution. In this case, the crash occurs in the following code:
[+ full code]The vulnerability is triggered in ntdll.dll. The code corresponds to the function RtlAllocateHeap when a new node is added to the double-linked list of heap chunks. As can be seen, both EAX and ECX contain arbitrary values controlled by the attacker (0x41414141). This is the Call Stack when the crash occurs:
[+ full code]The problem is found in the function 0x65a310:
[+ full code]According to the .MBM format [3], the structure of an MBM is the following (beginning with a Header Section):
[+ full code]The MBM Jumptable is an LListL of offsets in which each offset points to a Paint Data Section. An LListL is basically a list where, as can be deduced from [4], the first letter ("L") represents the encoding of the list size indicator and the last letter ("L") represents the size of each element of the list. In this case, we have a list of LONGs and the size of this list is encoded as a LONG. So in our case, we have the following:
[+ full code]Our MBM Jumptable contains the following:
[+ full code]This is a list with one element (there is only one drawing in the file). The structure of each Paint Data Section is described in [5]. Inside this structure, there is a field called "Encoding", represented as Long and which contains the following values:
[+ full code]The original value in our case was 0x00000000, that the encoding indicates as plain data. When we change this value to 0x00007a7a, XnView interprets the data as RLE encoding. According to the format documentation [5]: "RLE encoding consists of sequences of marker bytes with data bytes. A marker byte of 00 to 7F means that the next byte should be repeated that many times and once more. A marker byte of 80 to FF means that (100-marker) bytes of data follow."
The function 0x65A310 is responsible for handling this encoding and copying the data indicated by the marker byte according to the encoding indicated by the "Encoding" field. In our case, the encoding field contains the following values:
[+ full code]We now look with more detail at that function, and how it handles data:
[+ full code]In this part, the program uses the third byte of the encoding, that is 0x7A, and since it is greater that 0, jumps to:
[+ full code]As we can see, in this part it takes the marker byte (0x7A), increments it by 1 (0x7B) and copies the following byte (0x41) the number of times indicated by the marker byte, but the buffer has only 0x32 bytes allocated. Below those 0x32 bytes we find the header of another chunk on the heap:
[+ full code]0x31355A0 is the beginning of the header of the next chunk. After executing REP STOS, the corruption of the header of that chunk occurs:
[+ full code]The error is the following: since it copies DWORDs, instead of copying 0x1E bytes, it should have copied 0x0F bytes (0x1E / 2). Finally, the heap block is allocated in this part of the code:
[+ full code]9. Report Timeline
- 2010-05-27: Core Security Technologies notifies XnView of the vulnerability.
- 2010-05-27: The XnView author acknowledges receipt of the notification.
- 2010-05-27: Core sends a technical description of the vulnerability, and a Proof-of-Concept file that triggers the bug.
- 2010-05-28: The XnView author notifies Core that the vulnerability has been fixed, and that a fixed version will be released.
- 2010-06-02: Core asks XnView when the fixed version will be released, in order to coordinate the publication of the advisory with the release of a fixed version.
- 2010-06-03: The XnView author responds that version 1.97.5 will be available in 2 weeks.
- 2010-06-03: Core requests a more precise date for the release, and reschedules publication of its advisory to June 14th, 2010.
- 2010-06-07: The XnView author responds that the update will be available on June 14th.
- 2010-06-10: Core sends a second Proof-of-Concept, and asks the XnView author if it triggers a different vulnerability.
- 2010-06-11: The XnView author responds that the second PoC triggers the same vulnerability.
- 2010-06-14: Advisory CORE-2010-0514 is published.
10. References
[1] XnView website http://www.xnview.com/
[2] Proof of Concept files http://www.coresecurity.com/files/attachments/CORE
[3] MBM file format http://software.frodo.looijaard.name/psiconv/forma
[4] Basic elements: LListL http://software.frodo.looijaard.name/psiconv/forma
[5] Paint Data Section http://software.frodo.looijaard.name/psiconv/forma
11. About CoreLabs
CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://corelabs.coresecurity.com/.
12. About Core Security Technologies
Core Security Technologies develops strategic solutions that help security-conscious organizations worldwide develop and maintain a proactive process for securing their networks. The company's flagship product, CORE IMPACT, is the most comprehensive product for performing enterprise security assurance testing. CORE IMPACT evaluates network, endpoint and end-user vulnerabilities and identifies what resources are exposed. It enables organizations to determine if current security investments are detecting and preventing attacks. Core Security Technologies augments its leading technology solution with world-class security consulting services, including penetration testing and software security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core Security Technologies can be reached at 617-399-6980 or on the Web at http://www.coresecurity.com.
13. Disclaimer
The contents of this advisory are copyright (c) 2010 Core Security Technologies and (c) 2010 CoreLabs, and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.
14. PGP/GPG Keys
This advisory has been signed with the GPG key of Core Security Technologies advisories team, which is available for download at http://www.coresecurity.com/files/attachments/core