漏洞描述
nhttpd 1.9.6及之前版本中存在路径穿越漏洞。攻击者可利用该漏洞访问web server路径之外的文件。
漏洞分析
目录穿越
在main.c中,处理header处存在如下代码
![4fff508b18ed270c0aff814f1d1219d0.png](https://i-blog.csdnimg.cn/blog_migrate/1bd0d906f5c38d95623f826d37004c37.jpeg)
程序将会调用http_verify对每个header进行有效性验证,如上图1568行
当http_verify函数对header有效性验证通过后,会调用http_proc对header进行处理,以及后续操作
跟入http_verify方法中
![2de421e5343a135902e8bc60d82bab5a.png](https://i-blog.csdnimg.cn/blog_migrate/0dda482417b9c5880da94b2f28b7f40f.jpeg)
在header有效性验证环节(http_verify)中,http_verify方法验证了header是否可以被url解码、method是否效、以及是否存在”/../”目录变量这样的字符串等内容
![bc0acfd419b9f7f4a6dd948194edf054.png](https://i-blog.csdnimg.cn/blog_migrate/71268606e0382b0fc80f661d6bb26b58.jpeg)
上图:header是否可以被url解码http_decode_header_uri,该方法有三种可能的返回值,-1(error)/ 0 (不需要解码)/ 解码后的值。-1则返回400状态码
![cc9698dd61995ebd77e1c6f6ecc2025f.png](https://i-blog.csdnimg.cn/blog_migrate/397c000287e362ec006b5f898baf907b.jpeg)
上图:判断header 是否是GET/POST/HEAD method中的一个,不是则返回501状态码
![85f9c1302e64716d96c951c1473c4a59.png](https://i-blog.csdnimg.cn/blog_migrate/0e74c86b5762c855a47fca1cf7fc9cd3.jpeg)
上图:判断header中是否存在”/../”,存在则返回400状态码
在通过http_verify校验后,理论上是不允许出现”/../”这样导致目录穿越漏洞的字符串,导致漏洞产生的原因,需要接下来往后看。
通过验证的header,紧接着通过http_proc处理,如下图1571行
![d58b7f2a06338f601e219146a9857cd1.png](https://i-blog.csdnimg.cn/blog_migrate/6974a029916012a5187fb45875114d71.jpeg)
在该方法的290行处,可见使用http_header方法进行header解析
![91e1bb2801c2032709040bd6e276824d.png](https://i-blog.csdnimg.cn/blog_migrate/60370e63437e1e6dcb8bc4e9ed5ecfdb.jpeg)
http_header方法解析传入的header并在结构中返回我们的响应,如下图
![89d2e537112b67452723102a375e038b.png](https://i-blog.csdnimg.cn/blog_migrate/a15bbb942184cc7d0249003a5cdbfd5a.jpeg)
在该方法中存在如下代码
![5ec87101ee88051a72eda77567407ac9.png](https://i-blog.csdnimg.cn/blog_migrate/9f1d00f49515db2c2c35f607c5556537.jpeg)
如上图1507行,http_header方法调用strcutl方法对header_data进行解析
strcutl方法中60行处,存在如下图代码
![35a8d4bac59416ecbb7548155eae4c24.png](https://i-blog.csdnimg.cn/blog_migrate/5fcad3f0865141175c4b698b596bf058.jpeg)
此处代码的本意,是通过’’或’’切分传入的header字符串
这里解释一下””、””以及””:
CR:Carriage Return,对应ASCII中转义字符,表示回车
LF:Linefeed,对应ASCII中转义字符,表示换行
CRLF:Carriage Return & Linefeed,,表示回车并换行
由于操作系统的不同,Windows以及Linux等采用不同的换行方式:
Windows操作系统采用两个字符来进行换行,即CRLF();
Unix/Linux/Mac OS X操作系统采用单个字符LF()来进行换行
![35a8d4bac59416ecbb7548155eae4c24.png](https://i-blog.csdnimg.cn/blog_migrate/5fcad3f0865141175c4b698b596bf058.jpeg)
上图代码的本意,是通过’’或’’切分传入的header字符串,当for循环中原始header中出现’’,则认为是一行数据的截至,停止对dst变量进行赋值,此时dst变量中存放的为这一行完整的数据
但是在windows中,会使用进行换行,数据中的header会以如下形式存在:
1
”line1line2”
为了在切割header行时,为了不把””混入line1中,即避免存在”line1”情况的出现,程序通过判断原始header中逐位的字符是否是””,若该处字符是””,则continue,不将该字符””赋值给最终的dst变量
因此,程序在用这种方式处理”line1line2”这样的windows下的数据时,第一行的dst值会是”line1”,而不会是”line1”
但是开发者仅仅考虑在处理windows换行符(””)换行时的问题,并简单的将””去除,并没有意识到攻击者可能构造的特殊情况,例如:
1
“/../../../”
这样的payload,在经过程序处理时,可以安全的通过http_verify对”/../”的校验。然而这人个payload在strcutl方法中,””会被去除,最终dst值为/../../../。这样的dst数据,最终会导致目录穿越的产生
RCE
http_proc方法中的execve函数,如下图
![47a8ae3115f5594f7bc13895e3bd3c5e.png](https://i-blog.csdnimg.cn/blog_migrate/1f5fabc8a2326129dce051ecfe03a791.jpeg)
execve()的第一个参数指定准备载入当前进程空间的新程序的路径名,第二个参数指定了传给新进程的命令行参数,最后一个参数指定了新程序的环境列表。
而此处,rh->rq_filef可以通过目录遍历,通过”/../../../../bin/sh”,指定web服务目录之外的bin/sh文件,造成远程代码执行漏洞的产生
修复
官方给出的修复方案如上,这里不仅判断了当前字符是””,更是判断了””后一位字符是否是””。也就是说,只有””这样的windows换行符出现时,””会被去除原payload” /../../”经过此次修复,最终解析后的dst值仍为”/../../”
如果构造payload”/../../”,虽然可以去除””,但由于随后的””导致for循环的终止,此时dst值为”/”,仍不能满足目录穿越