Your printer is not your printer ! - Hacking Printers at Pwn2Own Part II
Hacking Printers at Pwn2Own Toronto 2022
Based on our previous research, we also discovered Pre-auth RCE vulnerabilities((CVE-2023-0853、CVE-2023-0854) in other models of Canon printers. For the HP vulnerability, we had a collision with another team. In this section, we will detail the Canon and HP vulnerabilities we exploited during Pwn2own Toronto.
- Pwn2Own Toronto 2022 Target
| Target | Price | Master of Pwn Points |
|---|---|---|
| HP Collor LaserJet Pro M479fdw | $20000 | 2 |
| Lexmark MC3224i | $20000 | 2 |
| Canon imageCLASS MF743Cdw | $20000 | 2 |
Analysis
Canon
Firmware Extract
Same as 2021, you can refer to Part I. The current version is v11.04.
HP
The firmware can be obtained from HP’s official website. However, unlike in 2021, it cannot be directly extracted using binwalk. The firmware is encrypted with AES, and it’s hard to decrypt directly from the information.
At first, our thought was to look for the firmware of the same series to see if there was an unencrypted version. However, there was no such firmware on HP’s official website that met our criteria. We initially considered tearing down the printer to dump the firmware, but during our search on Google, we stumbled upon an older mirror site. This site enabled directory listing, allowing us to access all the firmware stored on that mirror website.
However, the problem was that the mirror site only mirrored up to 2016 and didn’t have the latest information. Still, we later managed to glean the official directory structure from the website information, which helped us to obtain an unencrypted firmware from a similar series.”
After our analysis, we found decryption-related information in the Firmware from fwupd. By reverse engineering, we were able to identify the encryption method and the Key. We can use the key to decrypt the target version of the Firmware.
HP Collor LaserJet Pro M479fdw
- OS - Linux Base
- ARMv7 32bit little-endian
Vulnerability & Exploitation
Canon
mDNS (CVE-2023-0853)
Ｗe found a stack overflow on mDNS. mDNS protocol resolves hostnames to IP address within small networks that do not include a local name server and are usually used for Apple and IoT devices.
It is enabled on Canon ImageCLASS MF743Cdw(Version 11.04) by default.
Before we look at the detail of the vulnerability we need to talk about mDNS Packet Structure.
mDNS is based on the DNS packet format defined in RFC1035 Section 4 for both queries and responses. mDNS queries and responses utilize the DNS header format defined in RFC1035 with exceptions noted below:
The packet format:
+---------------------+
| Header |
+---------------------+
| Question | the question for the name server
+---------------------+
| Answer | RRs answering the question
+---------------------+
| Authority | RRs pointing toward an authority
+---------------------+
| Additional | RRs holding additional information
+---------------------+
(diagram from https://www.ietf.org/rfc/rfc1035.txt)
The header contains the following fields:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
(diagram from https://www.ietf.org/rfc/rfc1035.txt)
The answer section contains RRs that answer the question.
Resource record format:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
(diagram from https://www.ietf.org/rfc/rfc1035.txt)
The RDATA section varies depending on the ‘type’. When type=NSEC, its format is as follows:
The RDATA of the NSEC RR is as shown below:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next Domain Name /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(diagram from https://www.ietf.org/rfc/rfc4034.txt)
More details can reference to RFC6762.
Other element is not important in this vulnerability, so we won’t explain more here. More detail can be found at RFC6762, RFC1035 and RFC4034.
Where is the bug
When Canon ImageCLASS MF743Cdw is parsing the Answer field (type NSEC) in mDNS header, there is a stack overflow.
In the function bnMdnsParseAnswers, it will parse answer section.
int __fastcall bnMdnsParseAnswers(
netbios_header *mdns_packet,
unsigned int *ppayloadlen,
netbios_header *pmdns_header,
_WORD *anwser_rr,
rrlist **payload,
_DWORD *pinfo)
{
...
char nsec_buf[256]; // ------ fixed size on the stack
...
_mdns_packet = (int)mdns_packet;
p_payloadlen = ppayloadlen;
p_mdns_header = pmdns_header;
anwser_cnt = anwser_rr;
v66 = 0;
cur_ptr = &mdns_packet->payload[*pinfo];
v9 = *payload;
v10 = *payload;
do
{
v11 = v10 == 0;
if ( v10 )
{
v9 = v10;
v10 = (rrlist *)v10->c;
}
else
{
v6 = aBnmdnsparseans;
v10 = 0;
v67 = 0;
}
}
while ( !v11 );
while ( (unsigned __int16)*anwser_cnt > v67 )
{
...
if...
type = (unsigned __int16)pname->type;
if ( type == 28 )
goto LABEL_36;
if...
if...
if ( type != 0x21 )
{
if ( type != 47 ) // NSEC
{
...
goto LABEL_95;
}
v62 = 0;
v63 = 0;
zeromemory(nsec_buf, 256, v19, v20);
v47 = bnMdnsMalloc(8);
rrlist->pname->nsec = v47;
if ( !v47 )
{
bnMdnsFreeRRLIST((int)rrlist);
v50 = 2720;
LABEL_76:
debugprintff(
3610,
3,
"[bnjr] [%s] <%s:%d> bnMdnsParseAnswers error in malloc(NSEC)\n",
"IMP/mdns/common/tcBnMdnsMsg.c",
v6,
v50);
return 3;
}
maybe_realloc(v47, 8);
nsec = rrlist->pname->nsec;
nsec_len = bnMdnsGetDecodedRRNameLen(cur_ptr, *ppayloadlen, (char *)_mdns_packet, &dwbyte);
if...
if...
v51 = (_BYTE *)bnMdnsMalloc(nsec_len);
*(_DWORD *)nsec = v51;
if...
consume_label(cur_ptr, *ppayloadlen, _mdns_packet, v51, nsec_len);
v52 = dwbyte;
v53 = &cur_ptr[dwbyte];
v54 = *ppayloadlen - dwbyte;
*ppayloadlen = v54;
v55 = (unsigned __int8)v53[1];
v56 = (unsigned __int8)*v53;
nsec_ = v53 + 2;
*ppayloadlen = v54 - 2;
v57 = v56 | (v55 << 8);
nsec_len_ = __rev16(v57);
if...
memcpy((int)nsec_buf, nsec_, nsec_len_, v57); //-------- [1] stack overflow
for ( i = 0; i < (int)nsec_len_; ++i )
{
if ( nsec_buf[i] )
{
for ( j = 0; j < 8; ++j )
{
if ( 1 << j == (unsigned __int8)nsec_buf[i] )
{
if ( v62 )
v63 = 7 - j + 8 * i;
else
v62 = 7 - j + 8 * i;
}
}
}
}
*(_WORD *)(nsec + 4) = v62;
...
}
*pinfo = &cur_ptr[-_mdns_packet - 0xC];
*anwser_cnt -= v66;
return 0;
}
}
When it is parsing the NSEC(type 47) record, it does not check the length of the record. It will copy the data to a local buffer(nsec_buf[256]) at [1], which leads to a stack buffer overflow.
Exploitation
We can construct an mDNS packet to trigger the stack overflow. It does not have Stack Guard, so we can overwrite the return address directly. It also does not implement DEP. We can overwrite the return address with a global buffer which we can control to run our shellcode.
We finally chose BJNP session buffer as our target. It will copy our payload when we start a BJNP session.
We can run shellcode to do anything, such as modifying the website, changing the LCD screen, etc.
NetBIOS (CVE-2023-0854)
Ｗe found a heap overflow on NetBIOS. NetBIOS is a protocol for Network Basic Input/Output System. It provides services related to the session layer of the OSI model allowing applications on separate computers to communicate over a local area network. . Canon implemented the NetBIOS daemon by themselves.
It is enabled on Canon ImageCLASS MF743Cdw(Version 11.04) by default.
NetBIOS provides three distinct services:
- Name service (NetBIOS-NS) for name registration and resolution.
- Datagram distribution service (NetBIOS-DGM) for connectionless communication.
- Session service (NetBIOS-SSN) for connection-oriented communication.
We will focus on NetBIOS-NS (port 137).
Before we look at the detail of the vulnerability we need to talk about NetBIOS-NS Packet Structure.
NetBIOS-NS is based on the DNS packet format. It is defined in RFC1002 for both queries and responses. NetBIOS queries and responses utilize the NS header format defined in RFC1002 with exceptions noted below:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME_TRN_ID | OPCODE | NM_FLAGS | RCODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QDCOUNT | ANCOUNT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSCOUNT | ARCOUNT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(diagram from https://datatracker.ietf.org/doc/html/rfc1002)
The query will be placed after the header. The first element is QNAME which is a domain name represented as a sequence of labels, where each label consists of a length character followed by that number of characters. Other element is not important in this vulnerability, so we won’t explain more here. More details can be found at RFC1002.
Where is the bug
When Canon ImageCLASS MF743Cdw is parsing the NetBIOS in NetBIOS packets, there is a heap overflow. The vulnerability is in cmNetBiosParseName function. We can trigger it from ndNameProcessExternalMessage.
When NetBIOS service starts, it will initial netbios_ns_buffer. The buffer would be allocated 0xff bytes from the heap.
int ndNameInit()
{
sub_41C47A20((int)"netcifsnqendapp/IMP/nq/ndnampro.c", 0x44ED3194, 97, 0x64u);
netbios_ns_buffer = calloc(1, 0xFF);
...
return -1;
}
When parsing the NetBIOS-NS in NetBIOS packets, it will use ndNameProcessExternalMessage to process it.
int __fastcall ndNameProcessExternalMessage(Adapter *a1)
{
netbios_header *packet; // r0
unsigned __int8 *v3; // r6
int flag; // r0
int v5; // r5
int v6; // r0
int v8; // r4
char nbname[40]; // [sp+8h] [bp-28h] BYREF
sub_41C47A20((int)"netcifsnqendapp/IMP/nq/ndnampro.c", 0x44ED31AC, 178, 0x64u);
packet = (netbios_header *)a1->packet;
LOWORD(a1->vvv) = LOBYTE(packet->id) | (HIBYTE(packet->id) << 8);
v3 = cmNetBiosParseName(packet, (unsigned __int8 *)packet->payload, (int)nbname, netbios_ns_buffer, 0xFFu); //---- [1]
//heap overflow at netbios_ns_buffer
if...
flag = getname_query_flag((netbios_header *)a1->packet);
v5 = flag;
if ( flag == 0xA800 )
{
v6 = ndInternalNamePositiveRegistration(a1, (int)nbname, (int)v3);
goto LABEL_17;
}
if ( flag > 0xA800 )
{
switch ( flag )
{
case 0xA801:
v6 = ndInternalNameNegativeRegistration(a1, (int)nbname);
goto LABEL_17;
...
}
goto LABEL_14;
}
...
ndInternalNameNegativeQuery((int)a1, (int)nbname);
v6 = ndExternalNameNegativeQuery((int)a1, nbname);
LABEL_17:
v8 = v6;
assset("netcifsnqendapp/IMP/nq/ndnampro.c", 0x44ED31AC, 238, 100);
return v8;
}
At [1], the function cmNetBiosParseName does not calculate the length of the domain name correctly. It will copy the domain name to netbios_ns_buff, which leads to a heap overflow.
Let’s take a look at cmNetBiosParseName function.
unsigned __int8 *__fastcall cmNetBiosParseName(
netbios_header *netbios_packet,
unsigned __int8 *netbios_label,
int netbios_name,
_BYTE *domain_name,
unsigned int maxlen)
{
char v5; // r9
unsigned __int8 *v11; // r0
_BYTE *v12; // r1
unsigned int i; // r0
char v15; // r3
char v16; // r2
int v17; // r0
unsigned __int8 *v18; // r0
unsigned int v19; // r3
char *label_; // r0
unsigned int labellen_; // r4
unsigned int labellen; // t1
char *v23; // r5
unsigned __int8 *next[9]; // [sp+4h] [bp-24h] BYREF
...
if ( *v11 == 0x20 )
{
...
v17 = *next[0];
if ( *next[0] )
v5 = '.';
else
*domain_name = 0;
if ( v17 )
{
do
{
v18 = resolveLabel(netbios_packet, next);
labellen = *v18;
label_ = (char *)(v18 + 1);
labellen_ = labellen;
if ( maxlen > labellen )
{
memcpy((int)domain_name, label_, labellen_, v19);
v23 = &domain_name[labellen_];
maxlan -= labellen_; // ---------- [2] // it does not subtract the length of "."
*v23 = v5;
domain_name = v23 + 1;
}
}
while ( *next[0] );
*(domain_name - 1) = 0;
}
assset("netcifsnqecorelib/IMP/nq/cmnbname.c", 0x44A86D7C, 634, 100);
return next[0] + 1;
}
else
{
logg("netcifsnqecorelib/IMP/nq/cmnbname.c", 0x44A86D7C, 595, 10);
return 0;
}
}
The function cmNetBiosParseName will parse the domain from the label in the NetBIOS packet to the domain_name buffer and it has a verification. The verification will check that the total length of the label could not larger than maxlen, and a "." will be added between each label. But it does not subtract the length of "." characters so that the total length of the label can be larger than maxlen. It will lead to overflow.
Exploitation
Luckily, there is a useful structure nb_info to achieve our goal. We can use the heap overflow to overwrite the structure of nb_info.
The layout of heap memory:
The structure of nb_info and Adapter:
struct nb_info {
int active;
char nbname[16];
int x;
int y;
short z;
short src_port;
short tid;
short w;
Adapter *adapter;
char *ptr;
int state;
...
}
The structure is used to store NetBIOS name information, it also has a member Adapter to store the information of connection.
struct Adapter
{
int idx;
_BYTE gap0[16];
int x;
int fd_1022;
int fd_1023;
int y;
_WORD src_port;
_DWORD src_ip;
int vvv;
int packet;
_DWORD recv_bytes;
char* response_buf;
_DWORD dword3C;
};
Let’s back to ndNameProcessExternalMessage, if the flag of NetBIOS-NS packet is set to 0xA801, it will use ndInternalNameNegativeRegistration to process our NetBIOS name. The result will be written to Adapter->responsebuf.
case 0xA801:
v6 = ndInternalNameNegativeRegistration(a1, (int)nbname);
goto LABEL_17;
At ndInternalNameNegativeRegistration :
int __fastcall ndInternalNameNegativeRegistration(Adapter *adapter, int a2)
{
...
if ( v8 )
{
returnNegativeRegistrationResponse((nb_info *)v6, adapter, 3);
}
...
}
If the conditions are met, it will use ‘returnNegativeRegistrationResponse’ to handle the Response.
int __fastcall returnNegativeRegistrationResponse(nb_info *nbinfo, Adapter *adapter, int a3)
{
int v6; // r2
netbios_header *response_buf; // r5
int NameWhateverResponse; // r2
unsigned __int8 v10[20]; // [sp+4h] [bp-2Ch] BYREF
__int16 v11; // [sp+18h] [bp-18h] BYREF
int v12; // [sp+1Ah] [bp-16h] BYREF
maybe_memcpy_s(v10, 0x44ED3100, 20);
sub_41C47A20((int)"netcifsnqendapp/IMP/nq/ndinname.c", 0x44ED30DC, 2349, 0x64u);
if...
v11 = 0;
sub_40B06FD8(*(_DWORD *)adapter->gap0, &v12);
response_buf = *(netbios_header **)nbinfo->adapter->responsebuf;
NameWhateverResponse = ndGenerateNameWhateverResponse(response_buf, nbinfo->name, 0x20u, (char *)&v11, 6u);
if ( NameWhateverResponse > 0 )
{
response_buf->id = nbinfo->id; //------[3]
response_buf->flag = __rev16(a3 | 0xA800);
if ( sySendToSocket(
nbinfo->adapter->fd_1022,
(const char *)response_buf,
NameWhateverResponse,
v10,
(unsigned __int16)nbinfo->src_port) <= 0 )
{
logg("netcifsnqendapp/IMP/nq/ndinname.c", 0x44ED30DC, 2392, 10);
v6 = 2393;
}
else
{
v6 = 2396;
}
goto LABEL_9;
}
assset("netcifsnqendapp/IMP/nq/ndinname.c", 0x44ED30DC, 2372, 100);
return -1;
}
In [3], it will overwrite response_buf->id with nbinfo->id.
That is, if we can overwrite the nb_info structure and forge the structure of the Adapter, we can do arbitrary memory writing. We need to find a global buffer to forge the structure. We finally chose BJNP session buffer as our target. It will copy our payload when we start a BJNP session.
After we have arbitrary memory writing. We can overwrite the function pointer of SLP service with BJNP session buffer pointer.
int __fastcall sub_4159CF90(unsigned __int8 *a1, unsigned int a2, int a3, int *a4)
{
...
result = ((int (__fastcall *)(int *, char *))dword_45C8FF14[2 * v20])(&v38, v47);// SLP function
if ( !result )
goto LABEL_46;
}
return result;
}
It does not implement DEP. After overwriting the function pointer, we can use the BJNP session buffer again to put our shellcode. After that, we can use the SLP attribute request to control the PC and run our shellcode.
HP
Our target this time is the HP Color LaserJet Pro M479fdw printer, which is primarily Linux-based. This makes the analysis relatively simpler. Under the Web Service, there are numerous ‘cgi’ files providing various printer operations. These operate via the FastCGI method. You can refer to the nginx config to see which path corresponds to which port and service. The config can be found at rootfs/sirius/rom/httpmgr_nginx.
/Sirius/rom/httpmgr_nginx/ledm.conf
Where is the bug
/usr/bin/local/slanapp is responsible for handling scan-related operations and primarily listens on 127.0.0.1:14030.
We can see from rootfs/sirius/rom/httpmgr_nginx/rest_scan.conf :
If we access /Scan/Jobs, the request is forwarded to a FastCGI listening on the 14030 port. After analysis, we found that it was handled by /rootfs/usr/local/bin/slangapp. When we send a request to /Scan/Jobs, it will call scan_job_http_handler in slangapp.
Where is the bug
There is a stack overflow at rest_scan_handle_get_request in slangapp.
int __fastcall scan_job_http_handler(int a1)
{
...
int request_method; // [sp+14h] [bp-2Ch]
char *host; // [sp+18h] [bp-28h] BYREF
int port; // [sp+20h] [bp-20h] BYREF
char *uri; // [sp+28h] [bp-18h] BYREF
int pathinfo; // [sp+30h] [bp-10h] BYREF
int urilen[2]; // [sp+38h] [bp-8h] BYREF
int pathinfo_len; // [sp+40h] [bp+0h] BYREF
char s[132]; // [sp+44h] [bp+4h] BYREF
char dest[260]; // [sp+C8h] [bp+88h] BYREF
host = 0;
memset(s, 0, 0x81u);
port = -1;
uri = 0;
pathinfo = 0;
urilen[0] = 0;
pathinfo_len = 0;
memset(byte_5DBD0, 0, 0x9C4u);
v2 = ((int (__fastcall *)(struct httpmgr_fptrtbl **, int))(*rest_scan_req_ifc_tbl)->acceptRequestHelper)(
rest_scan_req_ifc_tbl,
a1);
if...
if ( ((int (__fastcall *)(struct httpmgr_fptrtbl **, int, char **, int *, int *, int *, _DWORD, _DWORD))(*rest_scan_req_ifc_tbl)->getURI)(
rest_scan_req_ifc_tbl,
a1,
&uri,
urilen,
&pathinfo,
&pathinfo_len,
0,
0) < 0 )
_DEBUG_syslog((int)"REST_SCAN_DEBUG", 0, 1193517589, 0, 0);
if...
v17 = 1;
if...
LABEL_7:
request_method = ((int (__fastcall *)(struct httpmgr_fptrtbl **, int))(*rest_scan_req_ifc_tbl)->getVerb)(
rest_scan_req_ifc_tbl,
a1);
if...
v3 = ((int (__fastcall *)(struct httpmgr_fptrtbl **, int))(*rest_scan_req_ifc_tbl)->getContentLength)(
rest_scan_req_ifc_tbl,
a1);
v4 = v3;
if ( (unsigned int)(v3 - 1) <= 0x9C2 )
{
v14 = v3;
v15 = 0;
do
{
if ( v14 >= 2500 )
v14 = 2500;
v16 = ((int (__fastcall *)(struct httpmgr_fptrtbl **, int, char *, int))(*rest_scan_req_ifc_tbl)->httpmgr_recvData)(
rest_scan_req_ifc_tbl,
v2,
&byte_5DBD0[v15],
v14);
if ( v16 <= 0 )
break;
v15 += v16;
v14 = v4 - v15;
}
while ( v4 - v15 > 0 );
*((_BYTE *)&dword_5DBC8 + v4 + 8) = 0;
if ( v15 < 0 )
{
v17 = 1;
_DEBUG_syslog((int)"REST_SCAN_DEBUG", 0, 0x475DA215, v15, a1);
}
}
else if ( v3 > 0x9C3 )
{
v5 = 0;
do
{
while ( 2500 - v5 > 0 )
{
v6 = ((int (__fastcall *)(struct httpmgr_fptrtbl **))(*rest_scan_req_ifc_tbl)->httpmgr_recvData)(rest_scan_req_ifc_tbl);
if ( v6 <= 0 )
break;
v5 += v6;
}
v7 = v5 <= 0;
v5 = 0;
}
while ( !v7 );
}
v8 = ((int (__fastcall *)(struct httpmgr_fptrtbl **, int, char **, int *))(*rest_scan_req_ifc_tbl)->getHost)(
rest_scan_req_ifc_tbl,
a1,
&host,
&port);
if...
v9 = ((int (__fastcall *)(struct httpmgr_fptrtbl **, int))(*rest_scan_req_ifc_tbl)->completeRequestHelper)(
rest_scan_req_ifc_tbl,
a1);
if ( v9 > 0 )
{
do
{
v10 = 0;
do
{
while ( 2500 - v10 > 0 )
{
v11 = ((int (__fastcall *)(struct httpmgr_fptrtbl **))(*rest_scan_req_ifc_tbl)->httpmgr_recvData)(rest_scan_req_ifc_tbl);
if ( v11 <= 0 )
break;
v10 += v11;
}
v7 = v10 <= 0;
v10 = 0;
}
while ( !v7 );
v12 = ((int (__fastcall *)(struct httpmgr_fptrtbl **, int))(*rest_scan_req_ifc_tbl)->completeRequestHelper)(
rest_scan_req_ifc_tbl,
a1);
}
while ( v12 > 0 );
v9 = v12;
}
...
result = (*(int (__fastcall **)(int))(*(_DWORD *)dword_65260 + 20))(dword_65260);
dword_594F0 = result;
switch ( request_method )
{
case 1:
result = rest_scan_handle_get_request(a1, v4, uri, (unsigned __int8 *)pathinfo, pathinfo_len); // ----- [1]
break;
...
default:
return result;
}
return result;
If the request method is GET, it will use rest_scan_handle_get_request at [1] to handle it. It also passes the pathinfo to this function.
int __fastcall rest_scan_handle_get_request(int a1, int a2, char *s1, unsigned __int8 *pathinfo, int pathinfo_len)
{
struct httpmgr_fptrtbl **v8; // r0
int v9; // r1
int v10; // r2
struct httpmgr_fptrtbl **v11; // r0
int v12; // r1
int result; // r0
int v14; // r0
int next_char; // r4
unsigned __int8 *v16; // r3
int v17; // r1
int v18; // t1
char *v19; // r5
int v20; // r5
int v21; // r0
int v22; // r7
size_t v23; // r8
int v24; // r0
char first_path_info[32]; // [sp+8h] [bp-D8h] BYREF
char second_path_info[32]; // [sp+28h] [bp-B8h] BYREF
char pagenumber[152]; // [sp+48h] [bp-98h] BYREF
if...
if...
if ( !strncmp(s1, "/Scan/UserReadyToScan", 0x15u) )
{
...
}
else
{
v14 = strncmp(s1, "/Scan/Jobs", 0xAu);
if ( v14 )
{
...
}
...
next_char = *pathinfo;
if ( (next_char & 0xDF) == 0 )
{
first_path_info[0] = 0;
LABEL_37:
_DEBUG_syslog("REST_SCAN_DEBUG", 0, 0x411FA215, 400, 0);
v8 = rest_scan_req_ifc_tbl;
v9 = a1;
v10 = 400;
goto LABEL_6;
}
v16 = pathinfo;
v17 = 0;
do //------------------------------------------------------ [2]
{
if ( next_char != '/' )
first_path_info[32 * v17 + v14] = next_char;
v19 = &first_path_info[32 * v17];
if ( next_char == '/' )
{
v20 = 32 * v17++;
pagenumber[v20 - 64 + v14] = 0;
v19 = &first_path_info[v20 + 32];
v14 = 0;
}
else
{
++v14;
}
v18 = *++v16;
next_char = v18;
}
while ( (v18 & 0xDF) != 0 );
v19[v14] = 0;
if ( v17 != 2 || strcmp(second_path_info, "Pages") || dword_5DBC8 != strtol(first_path_info, 0, 10) )
goto LABEL_37;
v24 = strtol(pagenumber, 0, 10);
result = rest_scan_send_scan_data(a1, v24) + 1;
if ( result )
rest_scan_vp_thread_created = 1;
else
return rest_scan_send_err_reply(a1, 400);
}
return result;
}
But when it parse the pathinfo at [2], it does not check the length of pathinfo. Then copy the pathinfo to the local buffer(first_path_info[32]), which leads to a stack overflow.
Exploitation
We can construct the request to /Scan/Jobs/ to trigger it. It does not have Stack Guard, so we can overwrite the return address directly. But it has DEP, we need to do ROP to achieve our goal. Finally, we use ROP to overwrite the GOT of strncmp. After overwriting it, we can execute arbitrary commands when we access /Copy/{cmd}
However, in the end, this vulnerability collided with another team’s discovery.
Summary
Based on the results from Pwn2Own Austin 2021 to Pwn2Own Toronto 2022, printer security remains an easily overlooked issue. In just one year, the number of teams capable of compromising printers has significantly increased. Even in the third year, at Pwn2Own Toronto 2023, many teams still found vulnerabilities. It is recommended for everyone using these IoT devices to turn off unnecessary services, set up firewalls properly, and ensure appropriate access controls to reduce the risk of attacks.