CVE-2015-2080 Analysis

近日,GDS安全团队发现了一个Jetty Web Server的安全漏洞,并在其博客上公布了细节。根据其描述,Jetty Web Server在解析请求头并遇到非法字符时会抛出一个异常,该异常会将一块共享缓冲区内的部分内容作为HTTP400错误的Reason返回,导致了信息泄漏。

更多的代码细节可以参考GDS博客上的文章,下面以图文的方式来说明此次漏洞的成因。

上面已经说过了,Jetty Web Server此次的共享缓冲区信息泄漏是因为请求头中的非法字符触使服务端抛出异常,将共享缓冲区中的部分信息作为HTTP400错误的Reason返回,这里我们假设Shared-Buffer的大小为256 Bytes(实际默认配置是8192 Bytes),然后演示一下信息泄漏的过程(理想情况下,因为共享缓冲区不仅仅用于缓存请求信息)。

共享缓冲区如下图所示:

img

第一次请求(192 Bytes),经过服务端解析并放入了共享缓冲区:

img

然后含有非法字符的第二次请求(65 Bytes),经过服务端解析并放入了共享缓冲区,因为是共享的,所以前一次的数据只有后面部分没有被覆盖掉,也就是说该部分数据还暂时存在于共享缓冲区中:

img

由于非法字符使得服务端触发了异常,这时服务端就会将缓冲区的部分区域的字节信息作为HTTP400错误的Reason返回,情况如下(红色部分为泄漏的区域):

img

从上面的图可以看出,想要得到共享缓冲区之前留下的数据信息,只需要以16 Bytes作为步进值一直遍历就可以了,但实际上想获取之前请求中的完整数据真的有这么容易么?答案是否定的,因为该共享缓冲区不仅仅是存放请求数据,还会存放返回信息等,并且在站点访问频繁地情况下,并不能保证所得到数据的完整性。因为每一次正常或非正常的请求都会放入共享缓冲区,几乎不太容易甚至是不可能利用该漏洞来获取一些有价值的信息。下面是使用BurpSuite进行测试的结果(为了方便看偏移,截图直接用hex)。

第一次正常请求及其返回信息如下两图:

Request:

img

Response(后面会和第二次请求的长度做比较):

img

第二次为含有非法字符的请求,注意特别标准部分:

Request:

img

Response(注意红色标注部分,此处实际为上一次请求的返回信息部分,根据hex偏移可以看出):

img

再将第一次请求的返回信息和第二次请求的信息放在一起,就能很清楚地知道了:

img
img

综上可以得出结论,利用该漏洞虽然可以得到之前请求所留下的数据,但是由于其缓冲区的实时性和易覆盖性,想要很好的利用还是非常艰难。