Tomcat CVE-2018-1305 分析
（360 A-TEAM 长期招收高级安全研究人员，APT 攻防人员，请联系 wufangdong@360.net）
两个 CVE
CVE-2018-1305
CVE-2018-1304
从造成的影响方面来讲，都是鸡肋。从原理上讲有点像，基本可以认为是同一个。从分析角度来讲，这两个都比较简单。
这里只对 CVE-2018-1305 进行简要分析。
背景知识
Java EE 提供了类似 ACL 权限检查的注解，可以直接用于修饰 Java Servlet，用于对 Servlet 进行 ACL 保护。
简要分析
现假设有两个 Servlet：
Servlet1，访问路径为 /servlet1/*
Servlet2，访问路径为 /servlet1/servlet2/*
Servlet1 上有如下图的 Security Constraint（简单理解就是 ACL）：
Servlet2 上并没有 ACL。
然而因为 Servlet2 的访问 url 位于 Servlet1 的下一级（/servlet1/servlet2 是 /servlet1/ 的 “子目录”），所以 Tomcat 中正常的代码逻辑应该是，虽然 Servlet2 上面没有 ACL，但是 Servlet2 应该继承 Servlet1 的 ACL。
正常情况应该是：
先访问 /servlet1，返回 403，因为请求被 ACL 拦截了
再访问 /servlet1/servlet2，返回 403，因为请求被 ACL 拦截
那么实际的问题在哪里？
Tomcat 在接收到 Servlet 访问请求后，在实例化 Servlet 对象之前，会先扫描被访问的 Servlet 上注册的 ACL。如果存在 ACL，则将 ACL 规则添加到一个 Context 唯一的列表中。随后再检查当前访问的 Servlet 是否被 ACL 保护。
ACL 扫描 org.apache.catalina.authenticator.AuthenticatorBase#invoke：
ACL 检查 org.apache.catalina.authenticator.AuthenticatorBase#invoke：
问题出在，如果在 Servlet1 （/servlet1）被访问之前，有人先访问了 Servlet2（/servlet1/servlet2）。流程如下：
Tomcat 接收到 Servlet2 的访问请求
Tomcat 扫描 Servlet2 上注册的 ACL，发现 Servlet2 上没有注册 ACL
Tomcat 检查 Servlet2 是否被 ACL 保护。这一步，因为 Servlet2 在 Servlet1 之前被访问，所以导致 Servlet1 上注册的 ACL 规则还没有被 Tomcat 发现。所以，原本应该被 Servlet1 的 ACL 规则保护的 Servlet2，就处在了未受保护的状态。
实例
访问 http://localhost:8080/CVE-2018-1305/servlet1/servlet2，此时 servlet1 的 ACL 没被 Tomcat 加载，所以访问成功
访问 http://localhost:8080/CVE-2018-1305/servlet1，被拒绝访问了，此时 Tomcat 加载了 servlet1 的 ACL
再访问 http://localhost:8080/CVE-2018-1305/servlet1/servlet2，被拒绝访问了，因为 Tomcat 已经加载了 servlet1 的 ACL
Tomcat 的修复
Tomcat 的修复了 ACL 注册的方式。以前是采用，在 Servlet 真正被访问之前才去注册此 Servlet 上的 ACL。现在改成了，在 Context 启动的时候，就去扫描该 Context下所有的 Servlet 上注册的 ACL，并添加到 acl 列表中。
在任何一个 Context 启动时，Tomcat 都会自动调用：
org.apache.catalina.startup.WebAnnotationSet#loadApplicationServletAnnotations
而其中，添加了如下 ACL 相关代码：
影响范围
只有当你使用的 Tomcat 处于受影响的 Tomcat 版本，而且你的应用依赖于 Java EE Constraints 来进行 ACL 保护的时候，才受影响。
360 A-TEAM 是隶属于 360 企业安全集团旗下的纯技术研究团队。团队主要致力于 Web 渗透，APT 攻防、对抗，前瞻性攻防工具预研。从底层原理、协议层面进行严肃、有深度的技术研究，深入还原攻与防的技术本质。
欢迎有意者加入！