log4shell漏洞是如何工作的？

Question

Log4shell正在报道这个新闻。广泛使用的日志工具Log4J中的一个漏洞使许多服务器甚至一些桌面应用程序面临远程代码执行的风险。

这个漏洞是如何工作的？是什么错误使它成为可能？这与格式化字符串和${jndi:...}有关，但是为什么这样的字符串会导致远程代码执行？

我正在寻找一个没有任何Log4J或高级安全问题经验的IT专业人士的水平的解释。有点像你将如何解释SQLi或XSS给一个新的web开发人员。

Answer 1

简而言之，据我理解，漏洞是由以下原因造成的：

• 将用于日志记录的数据视为受信任的数据，尽管它们可能来自不受信任的源(例如记录HTTP请求的用户代理)
• 结合log4j2中强大的字符串扩展
• 使用LDAP或RMI触发远程序列化Java对象的加载
• ，这将导致在实例化(反序列化)加载对象时执行代码。

详细地说，有几个设计问题导致了这个问题：

• log4j允许在日志字符串中进行字符串扩展，例如，${date:YYYYMMDD}。不幸的是，在默认情况下，这个特性一直持续到log4j 2.15.0 enabled，尽管日志记录通常包括不受信任的用户输入，例如logger.debug(userInput)。出人意料的是，不受信任的输入<#>even的字符串扩展与参数化语句(如logger.debug("user said: {}", userInput) )一起工作。
• 远程攻击者不仅可以包含和触发像日期这样看似无害的扩展，而且还可以使用Java命名和目录接口 (即${jndi:ldap://host:port/whatever} )进行动态名称查找。这是一种具有多年来已知的大潜在攻击面的powerful机制--参见2016年这是年黑帽的演讲。
• 这个潜在的大型攻击面来自使用LDAP或RMI从远程系统加载序列化Java对象的能力。实例化这些对象需要反序列化，这可能导致代码执行。这可以通过利用安装的类中的一个bug来实现，比如在这个2015年年“阿帕奇公域”中著名而广泛的问题中。在某些情况下，甚至可以通过从远程加载尚未知道的类的代码来完成。换句话说：<#>Java的高度灵活性支持安全问题。

请注意，这里没有任何地方是一个实际的错误，它意外地通过。一切都是按设计运作的。只有设计没有在涉及记录不受信任数据的真实世界用例中提供必要的鲁棒性。