给我们的警示应该是那个老生常谈的问题:软件的使用者不是参与者。一个软件的使用者规模不能说明其参与者规模,更不能说明其可靠性。所谓的这么多人用没出事肯定没事这种云架构师观点早就应该被批判了。
正是因为用的人多,所以才更容易被黑客盯上,更容易被突破……
开源省不了钱,也不应当为了省钱而选择开源,你可以因为生态,因为定制化选择开源,但不应当是因为省钱,省到最后一无所有……
如果你有能力,就应当参与到开源项目中,审核所有的代码,提交自己的贡献。你没有这个能力,最好就是找个有商业背书的方案,开源技术照样有很多商业公司为其背书,花小钱省大钱。最惨的就是很多小公司,即没有能力参与开源项目,又买不起商业支持,那出了事儿除了加班又有什么办法呢?
更可怕的是,明明公司已经做大了,还不舍得IT投入,拿小公司自我安慰的:“那么多大公司用肯定没问题”的鬼话来哄骗自己,要清醒地认识到,那就是小公司没办法的自欺欺人而已……
就没人吐槽log4j是过度设计了么?这次的安全漏洞让很多用户无故躺枪,绝大部分用户引入log4j只是为了记录些简单的文本,压根没想到log4j还有这么强大的功能,能在字符串里执行远程代码。甚至有些用户都没直接引入log4j,只是因为第三方库用了log4j也躺枪了。
从设计上看log4j是支持动态的日志内容查找替换这种特性的,只要日志内容里存在${...}这样的查询文本,log4j就会执行并替换这些查询文本,而查询文本又被设计的非常强大,可以执行JNDI这样的远程服务。先不说这样会造成严重的安全性漏洞,就算把远程执行漏洞堵上了,在记录日志的模块里进行这种复杂的文本替换也会造成潜在的性能问题,如果用户恶意构造特定日志,可能对服务器产生拒绝服务攻击。
理论上说日志模块根本不需要这种强大的特性,如果业务需要这种查询文本替换的功能,完全可以引入一个独立的包,专门用于字符串格式化,这样的好处就在于程序员很清楚这个字符串格式化模块的特性,就不会在字符串模板里引入用户侧输入这种不可控的隐患。而日志系统记录用户侧输入是再常见不过的需求,如果记录日志时还需要担心用户侧输入会导致安全隐患,那这种日志模块就别用了,心智负担太大了。
刚刚才了解到官方发布了2个修复版本,都有被绕过的可能,看来要彻底修复这个漏洞只能禁用lookup,禁用JNDI。为了这个几乎不被用到的花哨功能,捅出了这个大个篓子,也是够夸张的。
我之前预言的拒绝服务攻击漏洞果然是被验证出来了,Log4j2大大小小修复了10个版本,依然没有把漏洞全部补上,正所谓过度设计一时爽,漏洞修复火葬场,设计一定要谨慎克制。
一个日志工具老老实实记录日志就行了,为什么要加载远程代码?
keep it simple, stupid!
1写日志不应该有远程执行代码的功能。
2如果某个第三方真想要这个高级功能,应该给写日志的函数,增加参数,或者再写一个函数,以区别。而不是给原函数直接增加代码。
3写日志有远程执行的功能,要写在说明文档的显耀位置,让调用者明白。
4这么看似弱智的bug,难道加这个功能的人真没想到?
5一个日志库,十几万代码。是没法看源代码的。
这是导致这个漏洞发生的,2013年的一次commit。
一个看起来很不错的需求,通过JNDI查询,记一条日志就把web服务上下文上所有的日志都拉下来?
然而,对于JNDI的URL、返回的LDAP数据等,却一点过滤都没有。因此可以构造恶意LDAP服务器响应,让运行log4j2的机子直接运行可引用的外部恶意类,也就是直接从外网URL,把恶意.class文件拉进来跑了。
看看log4j2官方怎么修复这次这个漏洞的吧。
这套补丁对log4j2的表达式查询JNDI插件添加了过滤特定协议、服务器、类的功能,默认只允许通过其对Integer、String之类的内置类型进行反序列化,只允许ldap、ldaps和java协议,只允许访问127.0.0.1、localhost和本机IP。
最后一条可以说基本把原来这个插件的功能给废了。
当初是谁commit了那个韩国名字的人的的patch的?
Ralph Goers可能当时根本就没考虑到这玩意还能这么用,以为用途真就只是用来从外部读一些数据这么简单,测试了一下就给commit了。没想到搞成了Shellshock、Heartbleed这种“互联网基础设施级别”的大漏洞。
一般人用log4j2只是记录个日志文件这么简单,连表达式查询功能都不会用,也用不上。但是这个功能是默认开启的,而且又默认开启了这么大一个漏洞出来。
这有时候也不能怪我们——很多时候软件中一个不起眼的功能只是为满足少数几个人的特殊需求去做的,可能时过境迁之后,当年开发这个功能的人都不活跃了,所有人都忘记了这个功能。
我们下游用户一般只管使用自己需要的功能,别说对上游的库进行完整测试了,甚至连配置都懒得去配置它,只管用。
这种用户一般用不上,开发者也容易忽视的小功能,如果不出这种大问题,就根本找不到谁能站出来负责。可能稳妥的办法是把这种小众功能模块改为白名单制,默认为不开启,出了问题损失能减少点吧。。
记得之前有个段子,说发明C语言的哥们,编写了一个Unix系统。使用系统的同事发现,无论自己怎么改密码、排查源代码漏洞,这哥们都能进去。
后来发现,哥们的后门开在C编译器里。
现在的系统,代码都以十万行记。一个十人年规模的系统,谁来检查安全漏洞?怎么查?
更不用说解释器、编译器和嵌在硬件里的漏洞。
很多人觉得人家都开源了,这怎么封锁我们?
太天真了。
开源代码不停地升级,你跟不跟?
天知道那个版本里就有0级漏洞。
你武装到家的系统,和没锁门的房间一样来去自如。
别看网上吵java和c谁优秀,能冒出一万个程序员。
真的能从以十万行记的代码里找到漏洞的人,全国也不到三位数。
这个漏洞影响太大,放在网络战术库里,谁都没底。
所以才叫核弹级漏洞。
战术级漏洞,太多了。
被大众所知的是少数。
一个日志框架,不想着做好本职工作,非得大而全,给你啥内容不直接显示,非得解析啥JNDI,真是NB。
除了过度设计问题,居然还把用户输入的参数放在解析函数的占位符参数的位置上。这种行为非常恶劣,基本相当于 SQL注入(直接拼接SQL语句),或者格式化字符串漏洞(直接把用户输入放在 printf的第一个参数)。
当然,这俩漏洞有些年头了,如果你这么做,IDE或者代码检查工具会提示你,但是JNDI注入是新的形式或者变体,IDE来不及更新规则库,就放行了。
还有一个令人诧异的点:JNDI注入漏洞已在Struts2框架中多次发现,其他Apache的开源项目就不想着检测一下?正所谓,前事不忘,后事之师。我从16年开始就听说Struts2的JNDI注入漏洞,这都过了五年还不当回事,甚至没见到有WAF默认能防这东西,真是心大。
老是出问题的开源框架会被抛弃
比如Struts2,比如FastJson,仅此而已
完全不用第三方组件进行开发
不是不可行,而是成本太高
高于开源框架漏洞造成的损失
我就想知道一log工具为啥被搞成可以执行代码…
这就像是对镜子说了句“镜子镜子,谁是世界上最漂里的女人”,结果却被识别为太丑而自动触发核弹进行精确打击。
这就是很多公司慎用开源软件,万一用到需要专人审核的原因了。
名气很大的项目,质量仍然可能不及格。
同时,这也是为何强调要“精确实现需求”,不要做多余的功能的原因之一了。
别以为耍个花活就能“免费”得到一堆功能很赚,代价就是也给了别人耍花活玩你的机会。
最后,就还是那句话:别把用户想的太善良!
尤其服务器程序,黑客就藏在其中,他会想尽办法搞破坏--以内行的眼光。
正常公司里,日志工具老老实实解析就是了,程序和数据必须严格区分--相关功能是通不过立项的。
这个应该叫软件供应链安全。
大公司采用一个软件、library的时候,都需要评估它的安全性、稳定性的。要不然随便一个开发人员引入一个library,就把系统搞掉了。
但实际上,企业对安全的重视普遍不够。
第一是业务重要性一般高于安全,很明显,一个安全但是没人用的系统是没什么人用的。
第二是,安全很难有效衡量。我投入100万能保证百分百不被黑吗?我投入10w能降低多少被黑概率呢?
“利用工具的同时我们是不是应该更注重基础原理?”
理论上,使用工具还是要探究下底层原理的。但这个“探究”也是需要成本的。
对企业来说,开发者需要review 各个底层库的代码,而且还要有安全经验的开发者,是一个非常大的成本。
对于个人来说,那么多底层框架,我应该读哪个,不应该读哪个,都比较麻烦。更何况,在此之前,谁能想到要细读log4j的代码呢……
开头,先来复读名人名言:她那时候还太年轻,不知道所有命运馈赠的礼物,早已在暗中标好了价格。——茨威格
log4j 此次漏洞警示我们,利用开源软件,虽然很方便快捷的实现了日志记录功能,那么,古尔丹,代价是什么呢?
开源库,虽然有那么多人可以随时盯着源码看,但这并不意味着其安全性是得到完全保障的。
不开源,会有无休止的重复造轮子问题,有浪费人力和时间的问题。开源虽然节省了这些,但也意味着你得把造轮子的精力,转移到替开源库审核其安全性和稳定性上来,让开源项目更加精益求精,这就是所谓代价。
利用工具的同时,应该更注重基础原理,这倒没错,无论是为了学习,还是为了保证其安全性。但有,多少公司有能力来支付这个成本,且确实支付了呢?这是一个有待讨论的问题。
另外,log4j作为一个日志工具,能够加载远程代码执行,感觉设计上有点太臃肿了,没有做到代码数据分离。也正因如此,攻击者能够利用用户可以控制向记录日志中输入数据的操作,来实现其特殊构造的请求,进而触发 Apache Log4j2 中的远程代码执行漏洞。
关于log4j更多的内容,可看下面的回答:
另外,再给大家分享一个关于开源库的事故,很是伤心。
Ant Design,作为非常优秀且使用广泛的 UI 框架之一,其开发者搞了一个自认为很有趣,但是对于很多用户来说很糟糕的圣诞节小彩蛋,进而引发了一连串的事故。
至今,你还可以在github上查到相关的issue记录:
君不见因为Ant Design的圣诞节彩蛋问题,炒了多少为政府部门开发项目的程序员,这还只是一个小小的圣诞节彩蛋而已,只是按钮上多了一坨白色的东西而已,只是鼠标放上去会"Ho Ho Ho!"而已。
我记得因为这件事,很多和军方有合作项目的企业都被审查了,要求解释清楚为什么在网络隔离环境下的代码会发生改变,毕竟军方考虑的是:你今天可以被第三方库随意加一个彩蛋,明天会不会被人植入木马、盗走我的隐私数据?会不会搞个震网攻击,破坏我的军事设备研究工作?
所以,这个彩蛋的效果不只是会心一笑这么简单,而是很严肃的事件。
另外,还有包括发改委在内的很多政府部门都开始紧急采取措施应对这个事件,一是担心木马病毒问题,二是圣诞节这种宗教意识形态与我国无神论的矛盾问题,等等。
由此可以见得,普遍流行的框架,不仅可能因为开发者的不小心,出现一些意外的安全事故。甚至,其可以刻意制造隐蔽的安全漏洞,来攻击使用者。
当然,这次或许只是圣诞节彩蛋,只是log4j的无心之举。
那么,下次呢?代价又是什么,古尔丹?
本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度,google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有