Dec2LHA Library Stack Buffer Overflow

vendor:

Scan Engine

by:

Project Zero

7,8

CVSS

HIGH

Stack Buffer Overflow

119

CWE

Product Name: Scan Engine

Affected Version From: N/A

Affected Version To: N/A

Patch Exists: YES

Related CWE: N/A

CPE: N/A

Metasploit: N/A

Other Scripts: N/A

Tags: N/A

CVSS Metrics: N/A

Nuclei References: N/A

Nuclei Metadata: N/A

Platforms Tested: Linux

2017

Dec2LHA Library Stack Buffer Overflow

The dec2lha library is the library responsible for decompressing LZH and LHA archives. The CSymLHA::get_header() routine has a trivial stack buffer overflow. We can see from this initialization that var_141C is a 1024 byte stack buffer, because 0x100 * sizeof(dword) = 1024. But later on in this routine, the index is checked to see if it's > 4096 bytes, this is incorrect. This is most likely a simple programmers error, bounds checking with the wrong size.

Mitigation:

Ensure that the code is properly checked for buffer overflows and that the correct size is used for bounds checking.

Source

Exploit-DB raw data:

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

The dec2lha library is the library responsible for decompressing LZH and LHA archives. The CSymLHA::get_header() routine has a trivial stack buffer overflow.

.text:00023D91 31 C0                          xor     eax, eax
...
.text:00023DAE 8D 95 E4 FB FF+                lea     edx, [ebp+var_41C]
.text:00023DB4 89 D7                          mov     edi, edx
.text:00023DC7 66 B9 00 01                    mov     cx, 100h
.text:00023DCB F3 AB                          rep stosd

We can see from this initialization that var_141C is a 1024 byte stack buffer, because 0x100 * sizeof(dword) = 1024. But later on in this routine:

.text:0002442C 88 0C 10                       mov     [eax+edx], cl ; eax = &var_41C edx=index
.text:0002442F 83 C2 01                       add     edx, 1 ; edx++
...
.text:00024408 81 FA 00 10 00+                cmp     edx, 1000h ; if (index > 4096) ...
.text:0002440E 0F 84 E9 02 00+                jz      loc_246FD ; oob

The index is checked to see if it's > 4096 bytes, this is incorrect. This is most likely a simple programmers error, bounds checking with the wrong size.

This code is typically run with SYSTEM/root privileges, I'm using Symantec Scan Engine on Linux to reproduce this issue, but all platforms and products using this code (e.g. Symantec Mail Security) are likely affected.

#0  0xf5606d95 in CSymLHA::get_header(SymLHA::_S_LzHeader*) () from libdec2lha.so
#1  0xf5607af4 in CSymLHA::GetEntry(SymLHA::_S_LzHeader*) () from libdec2lha.so
#2  0xf55e83d5 in CLHAEngine::ProcessChildren(IDecomposerEx*, IDecContainerObjectEx*, IDecEventSink*, unsigned short*, char*, CSymLHA*) () from libdec2lha.so
#3  0xf55e8a8f in CLHAEngine::Process(IDecomposerEx*, IDecContainerObjectEx*, IDecEventSink*, unsigned short*, char*, bool*, bool*) () from libdec2lha.so
#4  0xf5c137b5 in CDecomposer::DecProcess(IDecObject*, IDecEventSink*, IDecIOCB*, unsigned short*, char*) () 
#5  0xf5c143cb in CDecomposer::Process(IDecObject*, IDecEventSink*, IDecIOCB*, unsigned short*, char*) ()
(gdb) c
Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()

Because Symantec do not use -fstack-protector on Linux, exploitation is remarkably trivial. Exploitation is likely still possible on Windows, but may be more difficult as they do use /GS on that platform.

This issue is remotely exploitable just by receiving an email, visiting a website, and so on.


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