如何避免Log4J漏洞?

5

Log4J存在一个严重的安全漏洞,已经得到修复。但是我还没有找到一个易懂的解释来说明在一个日志框架中如何会存在安全漏洞。

看起来这似乎与“Lookups”有关。 https://logging.apache.org/log4j/2.x/manual/lookups.html

但这只是在配置文件中,而不是能够被注入的日志文件?

问题是:如何彻底关闭所有聪明的功能以防止任何未来的攻击?我只想要日志记录。

这似乎需要删除任何"$"符号,但这只是一个猜测。(还应该删除任何\n以避免日志文件欺骗。我总是写一个非常简单的包装器,以便能够执行此类操作。)

(我有一个非常简单的接口,所有的日志消息都通过它,所以很容易让我删除所有不在格式字符串中的"$"符号。)


提供CVE链接会更有帮助。 - tgdavies
1
“如何一劳永逸地杀死所有聪明的东西,以防止任何未来的漏洞。” - 回答:唯一可以百分之百确定没有其他人犯下错误导致日志不安全的方法是自己从头开始实现。然后你只能责怪自己。(在多个意义上...) - Stephen C
1
这里有一个易懂的解释:https://news.sophos.com/en-us/2021/12/12/log4shell-hell-anatomy-of-an-exploit-outbreak/。简短版的解释是:消息替换 + 一个巧妙的技巧,使log4j发送HTTP请求到黑客的机器。 - Stephen C
CVE-2021-44228参考链接 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228 - Ayush Billore
或者更详细的解释请参考 https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/。 - user14215102
正确的提问地点是https://security.stackexchange.com/。 - tkruse
2个回答

3
"唯一防止查找引起的漏洞的方法是完全禁用它们。根据log4j2团队的说法,实现这个目标的方法是附加Java参数。"

-Dlog4j2.formatMsgNoLookups=true

这个修复方案可以通过在用户输入中添加${...}序列来调用查询(例如记录URL中的查询),但需要注意的是,即使您使用参数或记录异常堆栈,查询也会应用于记录序列。代码中的查询序列不危险,因为它们是可控的,但来自用户的查询则是不可预测的。如果记录“错误的用户名:xxx”,您不知道用户可以输入什么来利用其他漏洞。
然而,您无法确定框架中是否存在其他严重错误,因此切换到其他日志框架是合理的选择。一个很好的选择是Logback,它由Log4j的原始作者启动。开发人员明确表示,他的框架与Log4j2引入的安全问题无关:

除非另有说明,我们说log4j时指的是log4j 1.x。我们还应强调,logback与log4j 2.x无关。它不共享代码,也没有log4j 2.x的漏洞。

这个漏洞显然已经修复在2.16.0版本中,但它只解决了那个特定的漏洞,危险的查找功能并没有被删除。

根据Sophos报告

Log4j的更新版本仍支持潜在危险的字符串“查找”系统,但是默认情况下不再启用基于网络的JNDI连接,无论是在同一台机器上还是连接到其他地方。

换句话说,log4j2仍然不安全,但比以前不那么荒谬的不安全。


谢谢。我应该明确一下,我有自己简单的日志记录程序,可以转到CommonsLogging或SLF4J,然后再到Log4J。因此,在我的程序中,我可以从非格式字符串的消息中删除所有"$"。这样就足够了吗? - Tuntable
我觉得很难相信有人会对已记录的序列应用查找,但是更糟糕的事情已经发生过了。另外,处理"\n"以防止欺骗消息也非常重要,因为这已经被用于某些不明攻击中。 - Tuntable
有什么原因导致 System.setProperty(log4j2.formatMsgNoLookups, true) 无法工作吗? - Tuntable
@NehaJaggi 可能不行,因为查找是4-2版本的“功能”。但考虑到涉及的无能和疏忽程度,我认为除非经过第三方的详细安全审计,否则不能再信任任何Java日志框架。 - 9ilsdx 9rvj 0lo
1
@Tuntable 请查看 https://twitter.com/apenwarr/status/1469440349496287232 - GhostCat
显示剩余4条评论

1
针对此类安全问题,将最新的信息集中在一个地方是有意义的。
请参阅官方Log4j关于此漏洞的信息:https://logging.apache.org/log4j/2.x/security.html 该文档列出了适用于不同版本Log4j的几种缓解措施。
我知道通常在StackOverflow上的做法是在答案中提供明确的步骤和示例,而不是链接到外部文档,但我相信敏感的安全漏洞应该是个例外。

1
谢谢,但我已经阅读了那个链接,它并没有解释任何东西。我怀疑真正的问题是他们正在从记录的序列中解析一些内容。 - Tuntable
安全页面已更新,如果有其他信息可用,将进一步更新。主页还提供了有关此问题的说明 - Remko Popma
好的,现在正在Meta上讨论log4j2安全问题的处理方式,您是否愿意在那里表明您的立场?https://meta.stackoverflow.com/q/413724/2945027 - Alex Guteniev
不,我认为log4j2页面上的任何内容都不能再被信任了。他们在安全领域证明了自己太无能了。 - 9ilsdx 9rvj 0lo

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接