Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: InfoSec Handlers Diary Blog - Dissecting a CVE-2017-11882 Exploit InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Dissecting a CVE-2017-11882 Exploit

Published: 2018-11-03
Last Updated: 2018-11-03 20:54:32 UTC
by Didier Stevens (Version: 1)
1 comment(s)

About a week ago, I was asked for help with another malicious RTF file.

Malicious RTF files can not contain VBA code, in stead, malware authors have to use exploits to achieve code execution. This one here has become a classic: an overflow in the font record of an equation editor expression (CVE-2017-11882).

Finding the payload with and was pretty straightforward (we've covered this before):

A cleartext command is easy to spot. But there are also CVE-2017-11882 exploits with shellcode and encoded commands, and there it's harder to find the shellcode and its entry point. My tool can help with the analysis ( takes binary data as input and parses it according to a format string used by the Python struct module).

The structure of an OLE stream with Equation Editor data has been explained in detail in several articles, like this one, explaining that such an OLE stream starts with an header for Equation Editor data in an OLE stream (EQNOLEFILEHDR), followed by an MTEF header and several MTEF records. can parse these headers and records, when it is provided with the appropriate Python struct format string. For a sample like this, the format string to use is: <HIHIIIIIBBBBBBBBBB40sIIBB140s -s 192 -H -c "0x23:" -d ebde7d335a855059225288e152720021f79289353a79593c8e1efbc787c3dc29.vir | -s 4 -d | -f "<HIHIIIIIBBBBBBBBBB40sIIBB140s:XXXXXXXXXXXXXXXXXXsXXXXs" -n "1: size of EQNOLEFILEHDR 9: Start MTEF header 14: Full size record 15: Line record 16: Font record 19: Shellcode (fontname) 24: Command"

Entry 16 is the Font record, and entry 19 is the fontname. The fontname is 40 characters long, and can be overflowed on the stack, leading to EIP control. In simple exploits, where the payload command is at most 40 characters long, the fontname will contain the command and the return address will be overwritten to call WinExec.

Selecting entry 19 extracts the command. When the command is more than 40 characters long, malware authors use an exploit that is a bit more complex. The fontname then contains shellcode (without 0x00 bytes) that calls WinExec with a command that is appended to the fontame record + overflow. The sample presented here contains such shellcode, that can also be extracted by selecting entry 19:

Here is the disassembled shellcode:

The command can then be found in entry 24:

The struct format string I'm using here with is specially crafted for this exploit: I saw that the command was 140 characters long (including terminating 0x00) bytes, and I encoded that in the format string: 140s.

A more generic format string looks like this: "<HIHIIIIIBBBBBBBBBB40sII*:XXXXXXXXXXXXXXXXXXsXX"

I terminated this struct format string with * (remainder), right after the font record format (BBB40sII). By using * at the end of a struct format string, I direct to dump up to 256 bytes after parsing the input (e.g. the remainder).

This last format string can be used to dissect various CVE-2017-11882 exploits.

Didier Stevens
Senior handler
Microsoft MVP

1 comment(s)
Diary Archives