竟然没人讨论针对xz-utils的攻击
xz-utils后门事件引发对开源软件供应链安全的深度反思,新视频资料揭示事件细节
该帖子围绕xz/liblzma库被植入后门一事展开,深入探讨了其对开源软件供应链安全性的影响,并对攻击者身份和动机进行了猜测。新增回复提供了一个关于该事件的Bilibili视频链接,进一步补充了事件的细节和影响。
1. 关键信息
- xz/liblzma后门事件: 知名压缩库xz/liblzma的5.6.0和5.6.1版本被发现植入了针对SSH服务器的后门,可能导致远程代码执行。
- 供应链攻击的复杂性: 攻击者通过长期潜伏在开源项目维护者身份下,逐步获得信任并注入恶意代码,显示了供应链攻击的隐蔽性和高技术性。
- FOSS安全性的争议: 事件引发了对“开源更安全”神话的质疑,讨论了FOSS在维护者资源不足、缺乏明确责任机制下的脆弱性,以及与商业软件在安全保障上的对比。
- 攻击者身份猜测: 许多用户猜测此次攻击可能与国家支持的网络战有关,并联想到近期美国司法部对APT31的起诉。
- Rust与内存安全: 有用户提问Rust语言是否能防止此类漏洞,讨论了内存安全和类型安全对抵御攻击的作用。
- 事件视频资料: 新增回复提供了一个Bilibili视频链接,该视频(带中文字幕)详细介绍了此次黑客攻击如何感染上世界上最重要的操作系统的过程,并感谢了参与翻译和制作的人员,以及事件中的关键人物Rich Jones。
2. 羊毛/优惠信息
- 无
3. 最新动态
- 无
4. 争议或不同意见
- FOSS安全性: 一部分用户认为FOSS的透明性使其更容易被审计,而另一些用户则认为FOSS缺乏明确的责任机制和资源,易受攻击,且“开源更安全”的说法被质疑。
- 商业软件安全性: 讨论中对比了商业软件(如RHEL、opnsense企业版)在责任机制和资源投入上的优势,但也有观点认为它们并非绝对安全,且可能存在“小白鼠”版本。
5. 行动建议
- 关注和贡献: 建议用户关注自己使用的开源项目,并考虑为维护者提供支持或贡献。
- 网络隔离: 建议用户对家庭网络进行隔离,特别是物联网设备,以防范潜在的内网传播。
- 谨慎更新: 对于关键系统,建议谨慎更新到受影响的版本,并关注官方安全公告。
- 观看事件分析视频: 建议用户观看新增回复中提供的Bilibili视频,以更深入地了解xz-utils后门事件的细节和影响。
看来本坛还是不够技术
被影响的到现在都在忙着patch,没被影响的不care
那说明本坛用户的段位还是不够高,以24x365 oncall的为主。这种攻击,zuck会亲自下场打补丁吗
我猜zuck可能已经不知道/不记得libxz是啥了 最多就是听一个briefing说 “we have a very very bad security vuln” 完全不知道也不care是什么vuln
行外人伸手:有大神用通俗易懂的语言解释一下这是什么吗
【引用自 789】:
a very very bad security vuln
which may lead to SSH server compromise
V2EX – 29 Mar 24
xz/liblzma v5.6.0/5.6.1 被植入了以 sshd 为目标的后门 - V2EX
Linux - @Death - Backdoor in upstream xz/liblzma leading to SSH server compromise原文 https://www.openwall.com/list
https://v2ex.com/t/1028288
这也水深火热了吗
所以是APT么 我在twitter已经刷到阴谋论说是61398干的了
这种能长时间憋住气不发作的攻击,确实不是某个图财的个人开发者的行为
我看有个comment说这个attacker最开始是从良的 中途才加入the dark side.
怎么都开始 dramatize 了,再续写 @Netflix 了哦
评论区不就是看乐子么
https://twitter.com/Blankwonder/status/1773921956615877110
处心积虑长期供应链潜伏/投毒,类似于要嗨阔你电脑完了先入职微软写系统。
因为成本高到不像个人行为,现时很多人怀疑是大国网络战的一部分。
【引用自 anon78435924】:
是大国网络战的一部分。
这不前两天DOJ刚正式起诉APT31么 好热闹
rust能防止类似bug吗?
github.com/libarchive/libarchive
Added error text to warning when untaring with bsdtar
libarchive:master ← JiaT75:added_error_message_to_warning_bsdtar_1561
opened 02:55PM - 02 Nov 21 UTC
JiaT75
+3
-4
Added the error text when printing out warning and errors in bsdtar when untarin…g. Previously, there were cryptic error messages when, for example in issue #1561, the user tries to untar an archive in a location they do not have write access to.
closes #1561
对于开源的软件基础设施轮子哥已经在知乎锐评过了
【引用自 anon78435924】:
供应链潜伏/投毒
小厨娘连这个都懂,还骗大家说不会魔法
V2EX注册90天后才能访问是什么智障设定……
【引用自 收束观测者】:
连这个都懂
真不懂,浅尝辄止知道一点概念。拷打我这毒怎么投的自由软件怎么提交测试合并那我就,张口结舌叻。
【引用自 收束观测者】:
还骗大家说不会魔法
真不会。我太想掌握超能力作版本之子赚大钱收大米在鄙视链中盘踞一个比较上游的位置狠狠践行温良老中价值观肆无忌惮尽情拷打了——但我真不懂超能力所以,我哭了。
msft居然有這麼hands on的principle
Mastodon – 29 Mar 24
AndresFreundTec (@[email protected])
I was doing some micro-benchmarking at the time, needed to quiesce the system to reduce noise. Saw sshd processes were using a surprising amount of CPU, despite immediately failing because of wrong usernames etc. Profiled sshd, showing lots of cpu...
shell直接看暈
请问 xz 的老相好 @tar 有何感想
archive版本
V2EX – 29 Mar 24
[安全警告] xz 和 liblzma 5.6.0~5.6.1 版本上游被植入后门,影响所有 x64 架构 Linux 和 macOS - V2EX
信息安全 - @baobao1270 - ## 影响范围xz 和 liblzma 5.6.0~5.6.1 版本,可能包括的发行版 / 包管理系统有: - Fedora 41 / Fedora Rawhide - Debian
早上看到了 下次我提前水贴
Not in security field, please take the below source with a grain of salt.
简单概括是一个 widely in use 的 compression library 被植入后门,可能会导致RCE(远程执行漏洞),使用 linux 或者 mac 的用户可能会受到影响。受影响的版本 5.6.0 和 5.6.1,并不算 widely in use,但 rolling release 的 os 可能包含这个版本。判断是否受影响可见这个FAQ
几个值得一提地方:
这个是 Microsoft 的程序员在做 postgres performance profiling的时候发现的,mailing list见此。
xz original maintainer 的声明。这个 blackdoor 是新加入(实际上有两年了)的 maintainer 引入的。original maintainer 和新加入的 maintainer 之间有过一些冲突。新加入的 maintainer 在给original maintainer 施加 pressure 让他 merge 自己的 commit。花了两年的时间取得信任并 take over control a big portion of this repo。
有人提到植入后门的 maintainer 在+8 的时区,IP 地址在新加坡但是拿 VPN 做跳板,考虑到这个 maintainer 直接使用拼音的 commit signature,不排除是身份伪装。现在我还没有看到是 govornament support 的 attack 的落实证据。
还是 foss 项目的 sustainability 问题,foss maintainer 被 abuse 和 exploit 已经很 well known 了,很多作为 industrial default 的项目只是靠几个为爱发电的 maintainer 在维护。上一个这样知名的应该是 heartbleed。heartbleed 之后 openssh 得到了一些大公司的帮助,xz 这个项目的 original maintainer 现在大概率 under huge pressure,现在两个 maintainer 的账户都被 github suspend 了……
xz 绝不是第一个有 sustainability 的issue的 foss 项目,尽管几乎每个人都受益于这样的项目,但是它们离用户太远了,因此这样的项目的责任很大资源很少,有条件的谭友可以考虑给自己常用的repo做点贡献吧,foss的maintainer是真的不容易。
Typo: openssh->openssl
【引用自 pix0】:
有人提到植入后门的 maintainer 在+8 的时区,IP 地址在新加坡但是拿 VPN 做跳板,考虑到这个 maintainer 直接使用拼音的 commit signature,不排除是身份伪装。现在我还没有看到是 govornament support 的 attack 的落实证据。
中国的States sponsored attacker好像确实不太在意伪装身份 Mandiant分析的61398的report就有写 键盘和OS都直接用简体中文 并且很规律的上班时间 毕竟可能朝廷的人不怕被抓吧
这种问题不是应该在v2ex上讨论吗?话说我个人电脑用的mint是不是也会中招
个人电脑防火墙做好了(默认设置就够用了)不用担心这些问题
The end of an utopia
FOSS更安全的神话也该破灭了
这种supply chain attack跟FOSS关系其实没那么大,FOSS起码真的有人看着。
supply chain security这几年感觉热度挺高的
感谢,感觉要折腾下iptables了。不过话说我个人电脑并没有公网IP,家里网络一层NAT,在套一层carrier grade NAT,应该是安全的吧
显然不行,type safe和memory safe也阻止不了你直接往里面灌恶意代码啊
memory safe了起码能少掉很多利用memory做的攻击,每次看到c函数一堆safe_前缀的函数名就头大
type safe确实是跟安全没关系了
你有什么需要expose到外网的需求吗?看你的描述你应该没有吧,不然CGNAT够你头疼了已经。
我现在的默认设置是只expose一个wireguard的端口,其他交给wireguard
安全性跟几层NAT其实没关系,你的这个情况更要小心的是家里的设备有被感染了那种主动去连接远程服务器的恶意软件,防火墙只能防住外网进来的request,内网出去的更要小心,现在家里那么多IOT设备,每一个都是潜在的风险,你可以考虑做一个家庭网络的隔离。给你参考一下我现在家里分了三个网络,IOT设备一个,guest一个,还有主网络一个
对security方面一窍不通
【引用自 peridot】:
这种supply chain attack跟FOSS关系其实没那么大,FOSS起码真的有人看着。
FOSS更安全的神话来源于“开源所以任何人都可以审计代码”
然而事实上你看看楼上的这篇文章以及之前OpenSSL的那个大炸弹就会知道别说自备干粮的审计者了,连自备干粮的维护者都不够用
就算是作为high stake holder的那些跨国企业里,资本主义运行方式注定就是security这种纯cost部门不可能得到很多资源做de-risk直接法律风险以外的工作。
相比之下attacker去审计,乃至渗透FOSS的利益驱动力要大得多得多。
FOSS代码作为一个信息对等的透明战场,当攻击者的利益驱动力比防御者大的多得多的时候。注定防御者会被一次次击破
我记得之前在哪里读到过,即使程序的源代码是可靠的,编译器也有可能被人动手脚来生成恶意代码,程序员总不可能去review生成的二进制文件吧
刚刚google下,好像这个问题很早就被人提出来了,叫做The Ken Thompson Hack
【引用自 lemonch】:
即使程序的源代码是可靠的,编译器也可有可能被人动手脚来生成恶意代码
本质依然是供应链攻击,主楼这次就是编译时注入
但是作为FOSS的对位,大公司如果内部出现了attacker也一样存在这个问题,反而被审查的注意力会更小
Boeing表示不赞同
【引用自 peridot】:
大公司如果内部出现了attacker也一样存在这个问题
大公司有极高的liability和相应的利益驱动去设置流程和规则防范internal malicious actor
【引用自 pix0】:
Boeing表示不赞同
泥潭官方语言是英文实锤了,说中文总有人看不懂
本帖语境里“安全”一词指security而非safety
其实本来没想到这个栗子,但是楼上提到了波音,虽然不恰当,但是确实可以作为你这个说法的反例了
见补充回复
【引用自 收束观测者】:
大公司有极高的liability和相应的利益驱动去设置流程和规则防范internal malicious actor
重点不在security的定义(所以我才说不恰当),而在liability,现在眼前不就有一个仗着自己美国国企不能倒无视liability的存在吗
看上去只影响了非稳定版(debian testing/sid等),所以对普通生产机没有什么很大的影响。
对泥潭大部分人来说比较头疼的是说对openwrt有影响,但是没说版本,不过openwrt的版本也是散到到处都是…只能说最近自己跑openwrt又改了防火墙设置的自求多福吧
还好我不用openwrt(
我openwrt套opnsense 还好openwrt干的事情不多基本就当个WAN的中转站
嗯?多套一层有啥用处么
opnsense是我的主力,但是有些东西在openwrt上跑更容易(e.g. tailscale),因为毕竟是个正常的Linux生态。
FOSS从头到尾是0 liability。波音正儿八经是要赔钱而且会损失市场的。两者的经济驱动力相差无穷大
Risk只要不是为0就迟早一定会出事。波音问题说到底是liability不够强导致对risk不够敏感。但就算这样也比FOSS的liability和risk管理要严格无数倍
不说别的,明天有人发一整套FOSS可以3D打印的飞机上网。你敢参加试航吗。波音出个新飞机试航招志愿者泥潭怕不是抢着去
所以你是从liability的强弱反推安全性,我是从审查可行性角度正推安全性。liability强有做安全的动力,但是有没有能力做到是另一回事,又是波音。
【引用自 收束观测者】:
波音出个新飞机试航招志愿者泥潭怕不是抢着去
我是不太敢的,我觉得泥潭敢的应该只有波音的fanboy了,还真没准有
【引用自 peridot】:
我是从审查可行性角度正推安全性
FOSS的审查“可行性”已经被反复证明在现实里不会被realize了。所以说
【引用自 收束观测者】:
utopia
相比之下资本主义经济利益驱动是人类社会几百年验证过的
【引用自 peridot】:
我觉得泥潭敢的应该只有波音的fanboy了
我不是波音fanboy但是我懂资本主义
试航这种东西就算把所有代码写死出一套专门的软件版本也要保证最大程度万无一失的
【引用自 收束观测者】:
FOSS的审查“可行性”
但是这次不也正是靠可审查性才被人找到的问题吗,相比之前棱镜门的事情没有whistlerblower能瞒多久呢 当然可能我们聊的场景不一样,我自己在家host的东西让我用闭源的是不太肯的,我跟同事交流这些开源东西的时候也经常会看一眼distribution有没有可疑的地方,职业习惯了属于是
【引用自 peridot】:
但是这次不也正是靠可审查性才被人找到的问题吗
首先这次的攻击从一开始就是依赖FOSS特性才成立的。等于FOSS说我挖了个坑,偶尔会有好心人填上。这个能叫优越性?
其次,这次漏洞被抓到跟代码审计一毛钱关系都没有。发现者是从CPU负载异常开始反查的。这种后门一旦被发现端倪盯上了,就算没有源码,拿汇编做分析也能发现根源
闭源的看到cpu异常负载还要再反汇编得查到什么时候。
以及发现讲了半天FOSS也跟开源可审查性没关系啊,如果你既要liability又要可审查性,那你是不是在找Google最喜欢干的大公司开源计划
【引用自 peridot】:
闭源的看到cpu异常负载还要再反汇编得查到什么时候。
你怕是没仔细看文章,发现者是按照我们系统狗最喜欢玩的黑箱解谜游戏反查到链接表异常的。到这一步已经可以确定有鬼一定会查到底了
说到底这个代码是编译时注入的根本不在liblzma源码里
【引用自 peridot】:
如果你既要liability又要可审查性,那你是不是在找Google最喜欢干的大公司开源计划
抱歉。0 liability是写在FOSS license里的,跟谁做的无关。不可否认大公司做FOSS会把公司内很多既定流程带进项目把项目质量提高很多。但是不改变0 liability的本质
除非你说的是把F去掉,提供源码但收费提供服务和保障的OSS那么另说
这20年FOSS过于时髦以至于大家都意识不到里面反常识的东西。不敢吃没有保质期的食物,不敢买没有保修的车。但是用没有保障的软件做各种要命的产品反而没问题
【引用自 收束观测者】:
但是用没有保障的软件做各种要命的产品反而没问题
这句话当然没错,但是对于供应链攻击,极端一点到thompson compiler attack里,你连手上的反编译器,debugger之类的全都没法信任,还得手撸一个反编译器出来才敢用 OSS不OSS已经无所谓了
以及没有FOSS license这种东西吧,至少我看了一下手上的apache协议,还是有允许加liability的term的,当然我不是律师,不构成法律建议
【引用自 peridot】:
允许加liability的term的
这是跟“可审计性”一样的myth
请举例license非0 liability的主流FOSS软件
另外允许衍生作品改term并不代表衍生作品也是FOSS
应该根本原因是那一坨老旧的build系统吧,导致review困难,和语言关系比较小
【引用自 peridot】:
memory safe了起码能少掉很多利用memory做的攻击
我没用过rust,不过据说有的rust里一堆unsafe不也一样的
【引用自 abc123】:
review困难,和语言关系比较小
这不就是rust的意义吗,让编译器把
【引用自 圆形箱装猪头鹅】:
刷题时要花很久才能做出暴力解,死活想不出最优的解法,如何突破瓶颈?
那帮写C的傻羊装最懂汇编的
都赶走,让代码多少像点人样,review起来轻松一点
我也没用过rust 不过隔壁kotlin给了nullsafe的选项结果还是一大堆的!!去override,我猜rust里也是提供了override的机制
【引用自 收束观测者】:
FOSS更安全的神话也该破灭了
【引用自 pix0】:
Boeing表示不赞同
【引用自 收束观测者】:
说中文总有人看不懂
下次troll会记得带狗头的
既然谭友take that seriously. 还是要说我并不觉得foss代码就更安全,也不觉得就应该信任大公司。实际上
【引用自 收束观测者】:
就算是作为high stake holder的那些跨国企业里,资本主义运行方式注定就是security这种纯cost部门不可能得到很多资源做de-risk直接法律风险以外的工作。
也提到了作为公司的limit。不到breach没人在意security[缺乏引用来源,身边统计学]。哪怕是这次xz的情况是在做performance profiling的时候发现本身也能说明问题了。通过liability倒推的方式我持保留意见,Boeing的情况是解决了提出问题的人的。不管是foss还是公司,最终还是要看公司的security team/maintainer或者社区的水平以及应对的willingness。
foss的信任与安全问题一直存在,xz的情况实际是之前一项研究的一个实例。当foss的影响力到了industrial level很容易成为target,而individual maintainer是一个非常fragile的component,这是本身是foss面对的问题,没有什么需要反对的。
还是要说:
【引用自 收束观测者】:
但是用没有保障的软件做各种要命的产品反而没问题
让大公司不白嫖foss的项目?不存在的。谭友也
【引用自 收束观测者】:
懂资本主义
应该能想象那些infrastructure的application都要收费得花多少钱在license上以及为什么要选免费的版本。这实际上也是foss community呼吁大公司承担起maintaining的责任的原因。
【引用自 收束观测者】:
波音出个新飞机试航招志愿者泥潭怕不是抢着去
波音已经失去了我的信任,新飞机,适航,还是志愿者,完全想不出除了嫌命长以外,去做的任何理由。
哪个公司会出问题……都是leading edge/bleeding edge的才vuln
如题,好奇Jia Tan到底是什么人
有,去隔壁讨论吧……
【引用自 未知】:
竟然没人讨论针对xz-utils的攻击 搬砖
看来本坛还是不够技术
我猜是俄罗斯的网军,毕竟他们有这个实力。如果是中国网军应该不会傻到用中文名。如果是美国人他们可能会选择买几个0day。
我还没见过哪个知名rust大型库不用Unsafe的
只调查 “Jia Tan” 没有意义吧,至少得同时调查 Jigar Kumar, Dennis Ens, Hans Jansen, krygorin4545, misoeater91, Sebastian Andrzej Siewior, Richard W.M. Jones, 这些人都在各邮件列表上加油助威了。
说到这个问题,我突然想起来opnsense是收钱的吧,免费版是小白鼠。
Opnsense和RHEL这种商业公司维护的收钱的开源软件理论上是最好的?
enterprise版有额外功能是基本操作了,不代表community版是小白鼠,enterprise版的额外功能你也用不上
但是enterprise版可以锁推送,community是滚动?
你可以不更新
而且社区版本的telemetry是要上传给官方的吧,官方的telemetry库就是从社区版来的。
等于是用提供tekemetry换免费使用。
data collection都是设置的时候自己选的啊,开源的东西强制上传就会有人fork了
时隔多年,居然看到Ve做了视频报道这个
真是活久见,但是做的挺好的
中文字幕
bilibili.com
互联网曾经距离灾难只有几周之遥,却无人知晓_哔哩哔哩_bilibili
一次黑客攻击是如何感染上世界上最重要的操作系统的?翻译:@贰鼠 、@TechCiel 封面制作:@綿雲飴里 额外翻译、审核、时轴、后期处理:Alice Zhang (Origami Alice) @折生万物 ---------------------------------------在此衷心感谢所有为此付出努力的人:Rich Jones,感谢他在整个项目中的坦诚相待。Denzel Far, 视频播放量 45132、弹幕量 656、点赞数 3369、投硬币枚数 1653、收藏人数...