最近遇到 CVE-2019-16869影响的 io.netty:netty组件的风险修复问题,但是 io.netty:netty全版本都有风险,无法通过升级的方式 解决组件的漏洞风险。
目前可以查到的信息也很有限,只有github上相关的补丁信息,
但是自己又对CVE-2019-16869的漏洞原理很感兴趣,网上资料了了,只说 Netty 错误地处理了 HTTP 标头,但是具体怎么错误处理的,以及修复的原理是什么,没有找到完整分析过的文章,
特此完整整理分析如下:
依赖坐标:
io.netty:netty
...
漏洞风险——Netty 存在 HTTP 请求走私漏洞
CVE-2019-16869
漏洞描述
Netty 是一个非阻塞I/O客户端-服务器框架,主要用于开发Java网络应用程序,如协议服务器和客户端。
Netty 的受影响版本容易受到 HTTP 请求走私的攻击,原因是 Netty 错误地处理了 HTTP 标头中冒号前的空格如 Transfer-Encoding : chunked 。攻击者可利用此漏洞进行 HTTP 请求走私攻击,绕过安全控制,未经授权访问敏感数据。
参考信息
https://nvd.nist.gov/vuln/detail/CVE-2019-16869
https://github.com/netty/netty/issues/9571
https://github.com/netty/netty/pull/9585
https://github.com/netty/netty/commit/017a9658c97ff1a1355c31a6a1f8bd1ea6f21c8d
漏洞原理 及 修复
CVE-2019-16869 ,这枚 CVE 是 OPPO 子午互联网安全实验室发掘的,是关于 Netty 中间件存在 HTTP Smuggling 漏洞。
HTTP请求走私漏洞的核心原因是由于前端服务器和后端服务器在处理HTTP请求头时存在差异,导致请求被错误解析。 例如,Content-Length和Transfer-Encoding头的处理不一致,可能导致请求被分割或合并,从而引发安全漏洞。
HTTP请求走私漏洞的类型包括:
- TE:前端服务器使用Content-Length,后端服务器使用Transfer-Encoding。
- CL:前端服务器使用Transfer-Encoding,后端服务器使用Content-Length。
- TE:前后端服务器都支持Transfer-Encoding,但处理方式不一致。
HTTP请求走私漏洞的危害包括:
- 会话劫持:攻击者可以利用该漏洞劫持用户会话,获取敏感信息如登录凭证和会话标识符。
- 身份伪装:攻击者可以伪装成合法用户,绕过安全机制,获得未授权访问权限。
- 敏感信息泄露:攻击者可能泄露用户的个人身份信息、金融数据等。
- 业务破坏:对业务逻辑和系统配置造成破坏。
在 Netty 4.1.42.Final 版本之前对于 Header 头的处理是使用 splitHeader方法,其中关键代码如下:
for (nameEnd = nameStart; nameEnd < length; nameEnd ++) { char ch = sb.charAt(nameEnd); if (ch == ':' || Character.isWhitespace(ch)) { break; }
}
其他的代码我们并不需要过多了解,这里我们可以知道这里将空格与:冒号同样处理了,也就是如果存在空格会把:其之前的 field name 正常处理,并不会抛出错误或者进行其他操作。这样就与 RFC 标准的规范不一致了,于是就会产生解析差异。
@Bi3g0 构建了比较清晰的漏洞原理图:
这里的例子是采用 ELB 作为 Front 服务器,Netty 作为 Backend 服务器进行举例,我们发送如下请求:
POST /getusers HTTP/1.1 Host:www.backend.com Content-Length:64 Transfer-Encoding :chunked
0 GET /hacker HTTP/1.1 Host: www.hacker.com hacker: hacker
elb是如何处理Incorrect TE:
1)攻击请求
POST /getusers HTTP/1.1 主机:www.backend.com 内容长度:64 传输编码:分块 0 GET /hacker HTTP/1.1 主机: www.hacker.com hacker: hacker
2)ELB处理请求的方式:
ELB 会将 Transfer-Encoding 字段忽略,因为它与冒号中间有一个空格,不符合 RFC 标准(参考 https://tools.ietf.org/html/rfc7230#section-3.2.4),
ELB 会使用 Content-Length 作为解析标准,于是会认为以上请求是一个完整的请求,继而扔给 Backend 服务器,也就是 Netty ,Netty 在这里会优先解析 Transfer-Encoding ,即使这个字段不符合 RFC 标准,但是因为它的实现方式不严格, 所以这里因为优先解析 Transfer-Encoding 的原因,它会将这个请求拆分为两个请求:
POST /getusers HTTP/1.1 Host:www.backend.com Content-Length:64 Transfer-Encoding :chunked 0 GET /hacker HTTP/1.1
Host:www.hacker.com
hacker:hacker
这样就造成了 HTTP Smuggling 攻击。
Netty 于 4.1.42 Final 版本修复了这个漏洞:Correctly handle whitespaces in HTTP header names as defined by RFC72…
Netty 可以识别TE[space]: field value为错误的标头或自定义标头。
1)Netty 可以识别TE[space]: field value 自定义 header,Netty 应该像 elb 一样根据 header 来分离请求CL并转发整个 header TE[space]: field value。
2)或者Netty可以识别TE[space]: field value为不正确的header,返回响应码400(Bad Request)。
当我们发送 field name 与 : 之间有空格的 header 请求时, netty 会“正确”地返回 400 ,如下说明:
代码补丁如下:
https://github.com/netty/netty/commit/017a9658c97ff1a1355c31a6a1f8bd1ea6f21c8d
for(nameEnd =nameStart;nameEnd <length;nameEnd ++){ charch =sb.charAt(nameEnd); if(ch ==':' ||(!isDecodingRequest() && Character.isWhitespace(ch))){ break; } }
以上为总结分析,如有其他建议可留言沟通
4A评测 - 免责申明
本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。
不得将上述内容用于商业或者非法用途,否则一切后果请用户自负。
本站信息来自网络,版权争议与本站无关。您必须在下载后的24个小时之内,从您的电脑或手机中彻底删除上述内容。
如果您喜欢该程序,请支持正版,购买注册,得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解!
程序来源网络,不确保不包含木马病毒等危险内容,请在确保安全的情况下或使用虚拟机使用。
侵权违规投诉邮箱:4ablog168#gmail.com(#换成@)