CVE-2024-0244 - A Heap Buffer Overflow in the Canon MF753Cdw Printer
CVE-2024-0244 - A Heap Buffer Overflow in the Canon MF753Cdw Printer
This post covers the discovery and exploitation of CVE-2024-0244, which is an unauthenticated heap-based buffer overflow leading to an arbitrary free() in the Canon MF753Cdw printer featured in Pwn2Own Toronto 2023. 🚀 Lots of the more obvious vulnerabilities have been exploited (especially against the proprietary cadm service), so I decided to start vulnerability research against something a bit more obscure that hadn’t been exploited before. This led to me exploring Canon’s drivers that interact with lesser-used services.
The MF753Cdw support page offered a handful of Windows drivers, one of which was for sending faxes. This seemed obscure enough, and I therefore chose it as a research target. After installing the fax driver in a Windows virtual machine, the usual Windows print dialog box contained a new entry for sending faxes. I then used Wireshark to capture the traffic once the fax job was submitted. 📡 Behind the scenes, the driver sends many SOAP messages to the printer to initiate the fax job before sending the actual fax payload. These SOAP messages are all sent to the /wsd/print HTTP endpoint.
After the fax job has been initiated, a SOAP message with a binary payload is sent to /wsd/print. This message stands out as it’s the only SOAP message in the fax flow to contain binary data. Upon closer inspection, the binary payload contains the information entered into the fax destination dialog, the file and filename to fax, the Windows username, the Windows machine name, and a few hundred bytes of unknown data. Taking a closer look at the binary payload showed that the byte before most of the strings held the length of the string.
Tinkering around with the length fields didn’t initially highlight any issues until I tried a large length value (0xff) for the length of the destination fax number. This caused the fax task to crash and subsequently reboot the printer. 🔄 Analyzing the printer logs showed a few free() related log messages just before the crash as well as register values. By (ab)using the UART shell, I patched all of the relevant calls to free() with the address of dtdo_free_with_log() so they would all log the address of what was going to be freed. The pointer passed to free() was fully controlled via a malformed binary fax payload that contained a large string length and lots of A’s as the destination fax number.