Researchers: Joey Rideout and Mohamad Yassine
Every once and a while a client hands me a vulnerability to analyze that's simply a tough nut to crack. This one: emsmtp.dll version 220.127.116.11 being flagged as vulnerable to CVE-2007-4607 by a well-known vulnerability scanner.
The client wanted me to confirm the finding before they prioritized work to remove this EasyMail SMTP DLL from a legacy product offering. Sounds straightforward, but it wasn't. My associate Mohamad and I had our work cut out for us.
The CVE Entry notes that version 6.0.1 of the DLL as vulnerable, but at the time of writing it has no documented fix version. Patch notes from Quiksoft, EasyMail's creator, are nowhere to be found because the company no longer exists and all related web assets are offline. The best we could find is a second-hand copy of a portion of the patch notes on a third-party community post:
QuickSoft Release Notes:
Release Date: February 15, 2007
Security: Fixed scripting related security issues.
Release Date: November 27, 2006
Feature: Added AUTH MSN. Set ESMTP_AuthMode property to 8.
Release Date: November 27, 2006
Feature: You can now add attachments using non-ASCII file names.
Feature: Added ConvertHTMLToAlternativeText method that allows you to convert an HTML string to a Plain text string.
Feature: Added NTLM Authentication. Set ESMTP_AuthMode property to 8.
Release Date: March 13, 2006
Fix: Calling ImportBodyTextEx could result in truncation of the HTML body text.
Release Date: February 9, 2006
Fix: When not using autowrap the message body could be truncated due to changes in prior version.
Feature: Code reviewed and additional buffer overrun protection added.
Fix: Multi-line response could cause problem with using the SMTP with SSL.
Feature: Adding 64 as an option flag will save the message with out any additional x-headers.
Lovely. We've got "additional buffer overrun protection added" in version 18.104.22.168 and "scripting related security issues" fixed in version 22.214.171.124. At this point I'm strongly recommending that our client removes the library as soon as possible, because it is unmaintained and appears to host any number of nasty security bugs. That said, the lack of any specific reference to CVE-2007-4607 being remediated in the patch notes meant that our analysis was still inconclusive since our client used version 126.96.36.199.
Inconclusive won't do. What now?
Public exploit code from way back in 2007 for the vulnerability was available, but it was meant for IE6 and Windows XP SP2. My client uses Windows Server 2016 and, well, not IE6. Is this vulnerability still a threat? Would it even cause unexpected behaviour on a modern platform?
Only one way to find out!
Our next approach was to simply run the exploit against version 188.8.131.52 as well as version 6.0.1. If the buffer overflow was triggered in the latter but not the former, then we would know that the exploit is executing properly and that a fix was introduced after 6.0.1 but before 184.108.40.206. That would be conclusive.
So while Mohamad did some digging online to find a copy of emsmtp.dll version 6.0.1, I got to work making the exploit code from 2007 workable again. Python being my language of choice, I figured out how to load and register the DLL as an ActiveX Object:
import win32com.client emlib = win32com.client.Dispatch("EasyMail.SMTP")
... and call the vulnerable function with the appropriate amount of characters to induce a buffer overflow:
# Exploit calls for >99999 chars passed to SubmitToExpress method aaa = "A"*199999 assert(10 == emlib.SubmitToExpress(aaa)) # Expect 10 or a crash print "Done. EasyMail SMTP SubmitToExpress appears to be safe."
And voila! When we registered version 6.0.1 of the DLL, it crashed hard. When we registered version 220.127.116.11, the program did not crash and exited normally.
The full Python-ified exploit code with more documentation for dependency setup is available here, should you ever be bored enough to track down your own copy of emsmtp.dll and overflow a buffer like it's 2007.
In the end, the client was happy and the library was promptly removed. I am reaching out to MITRE to update the CVE Entry for CVE-2007-4607 with an upper bound on the affected versions. Another small victory for Application Security.