这个漏洞是dlink提供HTTP服务的cgibin组件中的hnap_main函数的sprintf对字符串长度处理不当造成的缓冲区溢出。以下是分析学习过程，如果错误欢迎指正。

固件版本为DIR-806，下载地址：

下载完成之后，使用binwalk对固件进行分析提取。

分析./etc/services/HTTP/httpcfg.php可以看出，当请求连接为HNAP1时，程序会执行hnap程序进行解析。

查看usr/sbin/hnap正是/htdocs/cgibin的软连接。

分析/htdocs/cgibin的main函数可知，当接收到hnap类型的请求时，程序会执行hnap_main

继续分析hnap_main，可以看到hnap_main中的sprintf处，程序并没有验证$4寄存器的长度，造成漏洞。所以我们可以将传入的数据覆盖掉寄存器$s0-$s7、$ra

有函数开头可知 栈空间为0x248字节大小。

程序返回时：

所以我们可以覆盖$sp+0x244的位置，构造ROP。

这里使用qemu的用户模式对其进行调试分析。为了编写和操作方便。把命令写到sh脚本中
注意，cgibin程序的hnap_main函数会获取一些变量值进行判断才能到达sprintf处。如下图

主要的环境变量有REQUEST_METHOD、REQUEST_URI等等，因此调试时需要设置些环境变量，绕过判断。

使用gdb-multiarch -q ./htdocs/cgibin启动gdb
之后attach上本地的1238端口即可开始调试。

当执行完最后一个sprintf时。此时栈空间已经全部被填满：

此时执行完sprintf（即我们可控制）的地址是0x76fff298，$sp+0x244的地址是0x76fff4bc，之间相差548个字节。

使用ropper在libc中找到些合适的ROP，准备构造：

栈中被sprintf填充的数据过多，通过计算，存在溢出点的地址应为195+6*4字节处。

libc的基地址可以通过启动cgibin的pid，在/proc/PID/maps中查看：(我这里是使用了qume模拟了固件

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！