jenkins 与 Log4j2 的漏洞

jenkins 与 Log4j2 的漏洞

背景是我们弄了一个jenkins做Android的持续集成，然后昨天sa突然说我们的端口有漏洞，要我们尽快配置升级。

如何升级jenkins？

jenkins默认的升级中心是这个：https://updates.jenkins.io/update-center.json

但是 *** 作更新的时候提示更新失败：jenkins 升级到 2.227.1 失败. Fail to download from https://mirrors.tuna.tsinghua.edu.cn

最后找到的方法是：
在这个页面 https://${your-server-ip,eg:yeshen.org}/pluginManager/advanced
配置升级站点为：

https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json

等配置重新同步，同步完点升级即可。

我配置后2.324 (2021-12-06) ，更到最新版之后看起来功能正常（顺便把使用的插件也一并更新了）

Log4j2 的漏洞是啥？

Apache Log4j2某些功能存在递归解析功能，攻击者可直接构造恶意请求，触发远程代码执行漏洞。漏洞利用无需特殊配置，所有使用了log4j2组件的服务均可能受到影响
受影响版本：Log4j2 versions >= 2.0-beta9 and <= 2.14.1

细节可以参考这两个文章：

https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apache-log4j2-zero-day-exploited-in-the-wild-log4shell
https://www.tenable.com/blog/cve-2021-44228-proof-of-concept-for-critical-apache-log4j-remote-code-execution-vulnerability

The crafted request uses a Java Naming and Directory Interface (JNDI) injection via a variety of services including:

- Lightweight Directory Access Protocol (LDAP)
- Secure LDAP (LDAPS)
- Remote Method Invocation (RMI)
- Domain Name Service (DNS)

If the vulnerable server uses log4j to log requests, the exploit will then request a malicious payload over JNDI through one of the services above from an attacker-controlled server. Successful exploitation could lead to RCE.

个人看文章的理解来说，就是它支持远程加载JNDI服务，在解析日志的时候。

Java runtimes later than 8u121, then it is protected against remote code execution by defaulting “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”

这个功能关掉了安全验证，导致如果打印中的日志包含JNDI接口，log4j会自动加载，且在本地服务上执行。

处理方法可以是： 配置 “log4j2.formatMsgNoLookups” to “true”
也可以是升级版本到 log4j2 2.15

jenkins 是否受到 Log4j2 的影响？

jenkins 2.324(2021-12-06最新版) 中使用的是 org.slf4j:log4j-over-slf4j:1.7.32

实际日志解析是slf4j，而不是log4j，所以不受影响

不过sa确实是发现了我们的jenkins的一些网络配置问题，他顺手给修了