Fuzzing packed executables with McAfee's LiveSafe 14.0 on Windows

vendor:

LiveSafe

by:

Project Zero

7,8

CVSS

HIGH

Signedness Error Parsing Sections and Relocations

190

CWE

Product Name: LiveSafe

Affected Version From: McAfee LiveSafe 14.0

Affected Version To: McAfee LiveSafe 14.0

Patch Exists: NO

Related CWE: N/A

CPE: a:mcafee:livesafe

Metasploit: N/A

Other Scripts: N/A

Tags: N/A

CVSS Metrics: N/A

Nuclei References: N/A

Nuclei Metadata: N/A

Platforms Tested: Windows, Linux

2016

Fuzzing packed executables with McAfee’s LiveSafe 14.0 on Windows

Fuzzing packed executables with McAfee's LiveSafe 14.0 on Windows found a signedness error parsing sections and relocations. The attached fuzzed testcase demonstrates this and causes a crash in mscan64a.dll. The code runs as SYSTEM on Windows, with no sandboxing and is used to parse untrusted remote input. The code is trying to read a byte from 0x90000fff, which is obviously invalid.

Mitigation:

Ensure that all input is validated and sanitized before being used.

Source

Exploit-DB raw data:

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=817

Fuzzing packed executables with McAfee's LiveSafe 14.0 on Windows found a signedness error parsing sections and relocations. The attached fuzzed testcase demonstrates this and causes a crash in mscan64a.dll. I verified that this crash reproduces on Linux and Windows, all version of McAfee appear to be affected including the embedded version and the SDK.

Naturally, this code runs as SYSTEM on Windows, with no sandboxing and is used to parse untrusted remote input.

0:045> .lastevent
Last event: d34.13a4: Access violation - code c0000005 (first chance)
  debugger time: Tue Apr  5 15:02:40.009 2016 (UTC - 7:00)
0:045> r
rax=00000000306f1000 rbx=00000000306f1000 rcx=00000000ffffffff
rdx=00000001031d114f rsi=00000000031d1150 rdi=00000000306f4000
rip=00000000711a36fa rsp=00000000064748a0 rbp=00000000031ca880
 r8=00000000000005d3  r9=00000000306f0fff r10=8d00008661e82404
r11=0000000000000000 r12=00000000306f4000 r13=000000000647917c
r14=000000001070c1b8 r15=00000000031ca698
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
mscan64a!RetrieveSingleExtensionList+0x19844a:
00000000`711a36fa 0fb64a01        movzx   ecx,byte ptr [rdx+1] ds:00000001`031d1150=??

Okay, what happened there?

0:007> ub 
mscan64a!RetrieveSingleExtensionList+0x198437:
00000000`71fd36e7 8b45c8          mov     eax,dword ptr [rbp-38h]
00000000`71fd36ea 8b08            mov     ecx,dword ptr [rax]
00000000`71fd36ec 8d4101          lea     eax,[rcx+1]
00000000`71fd36ef 3bc7            cmp     eax,edi
00000000`71fd36f1 7332            jae     mscan64a!RetrieveSingleExtensionList+0x198475 (00000000`71fd3725)
00000000`71fd36f3 2bcb            sub     ecx,ebx
00000000`71fd36f5 8bd1            mov     edx,ecx
00000000`71fd36f7 4803d6          add     rdx,rsi
0:007> dd @rbp-38 L1
00000000`0c529018  0c52d7ac
0:007> dd 0c52d7ac L1
00000000`0c52d7ac  90000fff

So it looks like that calculation is used as an index into @rsi, which is obviously going to be oob.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39770.zip