Autocad DWG-AC1021 Heap Corruption

AutoCAD is a software for computer-aided design (CAD) and technical drawing in 2D/3D, being one of the world leading CAD design tools. It is developed and sold by Autodesk, Inc.

• Title: AutoCAD DWG-AC1021 Heap Corruption
• CVE Name: CVE-2013-3665
• Permalink: http://blog.binamuse.com/2013/07/autocad-dwg-ac1021-heap-corruption.html
• Advisory: http://binamuse.com/advisories/BINA-20130724.txt
• Patch: http://usa.autodesk.com/adsk/servlet/ps/dl/item?id=21972896&linkID=9240618&siteID=123112
• Vendor notified on: 2013-03-27
• Patch/Fix Released: 2013-07-10
• Advisory Published: 2013-07-24

AutoCad is vulnerable to an arbitrary pointer dereference vulnerability, which can be exploited by malicious remote attackers to compromise a user’s system. This issue is due to AutoCad’s failure to properly bounds-check data in a DWG file before using it to index and copy heap memory values. This can be exploited to execute arbitrary code by opening a specially crafted DWG file, version AC1021.

This version was the native fileformat of AutoCAD Release 2007. New versions of the format emerged but AC1021 is still supported in modern AutoCADs for back ward compatibility.

Details

The DWG R2007 file format The R2007 dwg format has sections and pages. There are system sections and data sections. The system sections contain information about where the data sections and their pages are in the file. The system sections are built based in two main data structures: a first header and a second header. In addition, there are two important sections in the file structure, the page map and the section map. Each one of this sections should be decoded using Reed Solomon algorithm and also could be compressed with a proprietary algorithm (which we will ignore). The file structure looks like this:

The DWG R2007 also known as AC1021 is well documented by the reversing effort of opendesign.

Vulnerability Details

Not surprisingly AutoCAD starts by parsing the 1st header. Among other things it reads the size and location of the 2nd header. Then from the second header it reads the position in the file where the page map is stored, the number of pages present in the file (page-count) and the maximum id (page-max-id ) a page shall have. The page map is stored in a single system section page and it is composed by tuples (Id, Size) where the Id is the page number. After the loading of the page map, begins the processing of the section map that eventually will load all the objects present in the draw. Graphically the data representing the page map on the file looks like this:

When each PageMap node is read two data structures are updated, a double linked list of page map nodes called PMapList and an id indexed array of node pointers called PMapArray. A quick description of this three entities follows.

The page map nodes

In memory the structure holding a page map node has the following fields:

• acc: Accumulator of the field size (64 bits)
• size: Size of the page. (64 bits)
• id: Number of the page. (64 bits)
• prev: Address in memory of the previous node. (32 bits)
• next: Address in memory of the next node.(32 bits)
• unknown: there are 2 unknown fields of 64 bits (Not used).

The page map linked list

And they are linked in the PMapList that looks like this:

The page map array

PMapArray is an array of node pointers maintained for quick access of the page map nodes. It maps the id to the actual page map node. A memory chunk of pages-maxid size is allocated for it as declared in the 2nd header.

The bug

When each new page map node is created its address is stored in the corresponding id position of the PMapArray array without checking its boundaries. Thus, enabling an arbitrary heap offset overwrite with a pointer to the recently created node. Details on the exploitation technique can be found in Joshep white paper or in the actual proof of concept exploit.