text:0041E430 push esi size, controlled from our buffer text:0041E42D lea ecx, fixed buffer of size 0x4 text:0041E42B add eax, ebx recalculate offset to src ptr text:0041E424 mov, 0 initialize dst buffer text:0041E421 lea eax, calculate offset to src ptr text:0041E407 mov esi, eax is a ptr to our buffer Below is the location of the underlying API:
I would always hit an out of bounds read before reaching this bug and it appeared like the function wasn’t working like the developers intended otherwise it would have been an easy to exploit logical vulnerability.
The problem was however, I couldn’t generate a packate structure that would reach the MoveFileExW. The function accepts three (3) arguments and is essentially a MoveFileExW call without any checks. Let’s take proxyIEMoveFileEx for example. Whilst some of these really stood out as highly exploitable functions, it wasn’t always possible to reach the vulnerable API. This function handles several different type of requests and the handlers are highlighted in blue in this function: The VulnerabilityĪfter sniffing some sample requests sent to port 50000 while attempting to print a page from a browser, I found the following important function, sub_41DBA0. This means that an attacker doesn’t even need to race a request to the FoxitProxyServer_Socket_RD.exe binary at all.
#Foxit reader pdf printer failed to initialize code#
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.
0 kommentar(er)
