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

2021-12-21 11:04:17 +08:00
 kisshere
目前 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. 越大越复杂越臃肿功能越多才能显示自己厉害
2326 次点击
所在节点    程序员
14 条回复
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
为什么不花费你的免费时间去帮助审计一下这些开源项目服代码呢?
或者是在不重复造轮子的情况下,做出小而美且功能和 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 躲过一劫(

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/823489

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX