log4j2 目前接二连三爆出的漏洞对于 elasticsearch 来说，到底该怎么设置？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 1099 天前的主题，其中的信息可能已经有所发展或是发生改变。

目前 log4j2 爆出的 CVE-2021-44228, CVE-2021-45046, CVE-2021-45105 - ESA-2021-31 漏洞

ES 的官方在论坛发布的帖子： https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476 整篇布局较为杂乱，看了半天都没看懂，是不是只需要设置“-Dlog4j2.formatMsgNoLookups=true”再重启 ES 就可以解决所有漏洞了？

PS. 顺便吐槽一下这个 log4j2 ，太典型的反映了当代程序员的思维：1. 喜欢重复造轮子.2. 越大越复杂越臃肿功能越多才能显示自己厉害

log4j2

漏洞

爆出

轮子

14 条回复 • 2021-12-22 18:23:06 +08:00

ikas

2021-12-21 11:11:37 +08:00

不要莫名扣帽子
1.任何软件随着使用广泛功能都会增长,功能增长意味着 bug 与安全问题会增多
2.安全问题想要一劳永逸根本不现实.这一次 log4j 也算是提醒那些万年不更新的公司 //个人..时刻保持关注安全与更新
3.如何配置?网上那么多关于漏洞的解析,还有 github 推送的补丁日志.认真看下就知道了..

wellsc

2021-12-21 11:21:49 +08:00

一句吐槽基本把整个信安行业存在的价值否定掉了

k9982874

2021-12-21 11:22:14 +08:00

不如捐助一下作者，帮助作者可以全职放在 log4j 上？

uSy62nMkdH

2021-12-21 11:39:50 +08:00

你这句吐槽毫无价值，就跟我这条评论一样

markgor

2021-12-21 12:38:37 +08:00

PS. 顺便吐槽一下这个 kisshere ，太典型的反映了当代程序员的思维：1. 喜欢伸手就來張嘴就噴.2. 越大越复杂越臃肿功能越喜歡用開源的卻還一毛不拔

thevita

2021-12-21 12:44:25 +08:00

看具体版本，log4j >=2.10 的基本问题不大, <2.10 的版本 “-Dlog4j2.formatMsgNoLookups=true” 这种方式无效
可行的 1) 替换 jar 强行往上升级的实际落地上问题比较多, 可能碰到诸如 jvm 兼容性等一些问题，尤其是 es 这种，稳定性无法保证, 2) 还有个办法 zip -q -d log4j*-core.jar org/apache/logging/log4j/core/lookup/JndiLookup.class, 把漏洞的 class 删掉，但是管理 /维护成本暂时比较高

ly020044

2021-12-22 08:18:18 +08:00

你都白嫖了，还要吐槽人家？别人欠你的？

Kinnice

2021-12-22 09:06:04 +08:00 via Android

为什么不花费你的免费时间去帮助审计一下这些开源项目服代码呢?
或者是在不重复造轮子的情况下，做出小而美且功能和 log4j 一致的开源组件。

2i2Re2PLMaDnghL

2021-12-22 10:22:47 +08:00

不用 Java ，但感觉 HardenVault 说的很有道理，只要给 JVM 加个插件，所有进入 JVM 的代码都强制验签名，把 RCE 视为 feature 而非 bug ，就能解决大多数问题。

实际上，我第一次听说反序列化漏洞的时候，我就暗藏疑惑，
1. 当然应该允许用户数据包含可以构成代码的部分；
2. 用户数据代码应该在沙箱（包括元解释器）中运行（大部分语言不提供沙箱）。

thevita

2021-12-22 12:40:27 +08:00

@2i2Re2PLMaDnghL

code sign 能提高利用成本，但解决不了漏洞, 跟配置成不允许加载远程类的效果差不多(控制代码源)，不一样可以有利用点么。

至于反序列化漏洞，不一定是数据中有代码，程序的行为逻辑由代码和状态（有状态代码 /逻辑 /应用）共同决定，能控制其一就可能控制 control flow ，反序列化漏洞有相当一部分是因为可以控制某写状态值导致的

Rorysky

2021-12-22 14:09:57 +08:00

Delete 太典型的反映了当代程序员的思维

INSERT 太典型的反映了 JAVA 生态程序员的思维

2i2Re2PLMaDnghL

2021-12-22 14:30:47 +08:00

@thevita 验签可以解决绝大多数类型的 RCE ，利用点就只能存在于现有逻辑而非语言机制中。除非你像 ios 那个漏洞一样搞出图灵完备的环境，否则能够被执行的逻辑本身就已经被限定死了。
你说的这个是随机性的反序列化漏洞，纯粹是写的有问题，每个发生点都各不相同。系统性的反序列化漏洞是指反序列化中常常发生的 RCE ，是有方法有效避免发生的。

thevita

2021-12-22 15:06:32 +08:00

@2i2Re2PLMaDnghL 我不说了可能吗？漏洞都是写的有问题啊，解决绝大多数类型的 RCE 这句话看 java 上的历史漏洞是对的，我到不认为有本质区别，就是利用成本不一样，不过安全本身就是成本的对抗

至于 java 里验签来解决加载不可信代码的问题, 暂时看收效不高，因为大部分时候禁止加载远程类就能提升相当的利用难度，但是。。。让业务升级个 jvm 小版本都推不下去，让升级个安全加固的 jvm 可能性大么..

作为研究方向我觉得还是很有价值的，落地暂时太难

2i2Re2PLMaDnghL

2021-12-22 18:23:06 +08:00

@thevita 主要是写得有问题推不了锅，语言机制有问题总有种被背刺的感觉

落地难倒是确实，因为 log4j 不是 2 躲过一劫（