Busting Myths in Foxit ReaderAugust 17, 2017 | Abdul-Aziz Hariri
UPDATE: Since publishing this blog, a Foxit representative reached out to us with the following statement:
"Foxit Software is deeply committed to delivering secure PDF products to its customers. Our track record is strong in responding quickly in fixing vulnerabilities. We are currently working to rapidly address the two vulnerabilities reported on the Zero Day Initiative blog and will quickly deliver software improvements. In the meantime, users can help protect themselves by using the Safe Reading Mode. We apologize for our initial miscommunication when contacted about these vulnerabilities and are making changes to our procedures to mitigate the probability of it occurring again."
We are pleased to know they reversed course on these bugs. We thank the folks at Foxit for reconsidering this matter. The Foxit team have been good partners in the past, and we look forward to working with them again in future.
In order to trigger these vulnerabilities, an attacker would need to bypass Safe Reading Mode. Sadly, the vendor decided not to fix the vulnerabilities due to this fact and provided the following statement:
We disagree that this mitigation is sufficient protection from these bugs. This blog describes the vulnerabilities and how they can be used to execute code.
ZDI-CAN-4724 (CVE-2017-10951) – Foxit Reader app.launchURL command Injection:
This vulnerability was found and submitted to us by Ariele Caltabiano (kimiya). The vulnerability exists within app.launchURL. I must admit that this vulnerability made me smile when I first saw it, especially since it looked similar to a vulnerability that I found in Adobe Reader in 2015 and patched last year: ZDI-16-285.
We’ve always assumed (or at least I did) that app.launchURL strictly takes URLs as arguments. In Foxit, this is not an accurate assumption at all because:
- It does not check whether or not the argument is an actual URL. In fact, it accepts full paths.
- It does not filter any file extensions and hence we can simply execute commands.
It not only fails to check the above, but it also passes the full path to a ShellExecuteW with the lpOperation argument set to open:
We can verify this further in WinDBG by executing:
And here’s a video that demonstrates the vulnerability:
ZDI-CAN-4518 (CVE-2017-10952) – Foxit Reader saveAs Arbitrary File Write
The myth says that this API is supposed to be used to save the document (PDF file format) to certain paths. Well, Foxit Reader busted this myth. Here’s why:
- saveAs does not properly check the path it is given to write to.
- It does not check the file extension and hence we can simply write whatever we want.
Eventually, saveAs ends up calling WriteFile to write the file:
Steven exploited this vulnerability by embedding an HTA file in the document, then calling saveAS to write it to the startup folder, thus executing arbitrary vbscript code on startup.
The following trigger would write the file to the start up folder:
this.saveAs("/c/Users/”+ identity.loginName + ”/AppData/Roaming/Microsoft/Windows/STARTM~1/Programs/Startup/si.hta");
We can verify this in WinDBG:
Here’s a video that demonstrates the vulnerability:
A big shout out to our researchers who keep busting myths.