This means that an attacker doesn’t even need to race a request to the FoxitProxyServer_Socket_RD.exe binary at all. This gives an attacker executing code in a render tab a kind of race condition window, when the user attempts to print to PDF using the Foxit PDF Printer.Īfter more investigation into the issue, I later found out you can make calls to CreateDC API from some sandboxed processes to get a printer device context and then later create a print job with the default printer. Once a request is made, it closes the port and terminates execution. That brief second is due to the server listening on localhost port 50000 by default and accepting only a single request.

This essentially means that the FoxitProxyServer_Socket_RD.exe binary will be started, at medium integrity for a brief second. Once Foxit Reader is installed, the Foxit PDF Printer is the default printer used for handling print jobs. The PDF Printer is a relatively undocumented feature within Foxit Reader and is primarily used to handle print requests to a PDF file from any application. At the time, this was of course the latest version.

I tested version 9.3.0.912 of Foxit Reader with SHA1 of the FoxitProxyServer_Socket_RD.exe binary being: 0e1554311ba8dc04c18e19ec144b02a22b118eb7. TL DR I walk through the attack vector, analysis and exploitation of CVE-2018-20310 which is a stack based buffer overflow in the PDF Printer when sending a specially crafted proxyDoAction request. To my (un)surprise, I was able to discover several vulnerabilities in this component that could allow for a limited elevation of privilege, one being particularly nasty. In the spirit of catching foxes, I decided to look at a new component in Foxit Reader later in that same year. Then, as the second installment I blogged about a command injection in Foxit Reader SDK ActiveX. Mid last year, I blogged about how I found an exploitable use-after-free in Foxit Reader and how I was able to gain remote code execution from that vulnerability.

Foxit reader pdf printer