笔记本电脑的隐蔽漏洞，竟源于一首神曲的诅咒

　　2005 年，某＂主流计算机制造商＂在短时间内，收到大量的用户售后申请。
　　这些用户大多反馈的都是同一个问题：当电脑播放《Rhythm Nation》(节奏国度) 时，会出现崩溃，而播放其他歌曲时，电脑运行一切正常。
　　Rhythm Nation
　　更为诡异的是，不仅播放《Rhythm Nation》的电脑会崩溃，就连旁边没有播放这首歌的电脑，也会崩溃。
　　这个故障让受影响的用户头疼不已，有种自己电脑成精的感觉，让人忍不住怀疑这电脑是不是经历过什么，才会一听《Rhythm Nation》就丧失理智，崩溃摆烂。
　　面对这个诡异问题，这家电脑制造商也懵圈了，经过很长一段时间的排查，技术人员才找到问题所在：竟是共振惹的祸。
　　原来，如今电脑大都配备的是固态硬盘，但在 2005 年左右，很多笔记本电脑使用的是每分钟 5400 转的旋转硬盘，好巧不巧，《Rhythm Nation》这首歌的节奏韵律，正好暗合 5400 转硬盘笔记本电脑的＂自然共振频率＂，这才最终引起电脑崩溃。
　　众所周知，＂共振＂是一个工程问题，看似不起眼，但它的确引发过很多事故。
　　1940 年，西雅图微软总部附近的塔科马海峡大桥，在一个强风天轰然倒塌。造成倒塌的原因并非桥体本身质量不佳，而是因为受到大风所致的振动影响。
　　之前在某社交平台，有过一个热议的话题：士兵过桥时，为什么总是步伐混乱？原因同样是＂共振＂。一个流传甚广的新闻称，1831 年，英国布劳顿大桥之所以倒塌，就是因为过桥的士兵齐步走，引起了机械共振。
　　咱们说回电脑崩溃，现在原因找到了，但究竟该如何解决呢？毕竟在当时，市面上随处可见 5400 转硬盘的笔记本电脑，全部召回更换肯定不现实，但如果不解决，用户口碑就要丢了，这可真是进退两难。
　　幸好最后，这个问题还是得以圆满解决，办法就是：在音频管道中添加一个自定义过滤器，音频播放期间，这个过滤器能够检测并删除特定频率， 以此规避播放《Rhythm Nation》时造成的电脑崩溃。
　　这个引起电脑崩溃的工程漏洞，被 MITRE 组织赋予了 CVE 编号：CVE-2022-38392。MITRE 组织称，这是一个拒绝服务缺陷，可由通过《Rhythm Nation》MV 发起的＂共振频率攻击＂触发。
　　这个漏洞从发现到被爆出，中间隔了好几年，当人们知道这个事情时，已经不会有电脑因为这首歌而引发崩溃了，整场事件寥寥数言就能带过，但背后坎坷大多人不知。
　　针对这场风波，微软大神 Raymond Chen 戏称：
　　＂我确信他们给那个音频过滤器贴了个数字版的‘请勿移除’标签。（我猜这些年过去，可能已经没人知道为什么要加这么个东西在那里。）＂
　　微软大神 Raymond Chen
　　2022 年，＂安全左移＂成为云安全的热议话题，即便不是安全从业者，也有意无意能看到相关新闻。
　　安全为什么要左移？背后其实是＂墨菲定律＂在显灵。
　　＂墨菲定律＂的根本就是：凡是可能出错的事，很大几率会出错。
　　要知道，这里的＂事＂，并不只出现在当老师提问时，你坐在下面暗自祈祷＂千万别叫我＂，但你祈祷得越虔诚，被提问到的几率就越大。
　　墨菲定律里的＂事＂，指的是任何一件事。
　　安全从来不是一件绝对的事，这就意味着，如果一件事有可能导致安全问题出现，它就一定会导致安全问题。
　　2018 年 1 月 3 日，一组名为＂幽灵＂的漏洞 (spectre) 被公布。
　　这是存在于 CPU 上的漏洞，但注意，它不是某一款 CPU 的漏洞，而是现在 CPU 普遍存在的漏洞。
　　＂幽灵＂漏洞是一种旁路攻击方式。
　　旁路攻击是指利用程序等实体运作时产生的一些额外信息进行攻击的手段，这就像，小偷想知道某户人家有没有人，不会直接敲门，而是通过观察晚上开灯与否来确认。
　　＂幽灵＂漏洞可以通过攻击网页，非法获取到内存中的数据信息。但是，要想在浏览器中触发＂幽灵＂漏洞，需要用到高精度计时器。
　　正巧，一个叫做 SharedArrayBuffer 的前端跨线程共享数据方案，能够获取到高精度的 CPU 时间，而早在 2015 年，负责 JavaScript 标准设计的工作组，就将 SharedArrayBuffer 加入到了标准中。
　　于是，借助 SharedArrayBuffer，＂幽灵＂漏洞就能够轻易完成攻击。
　　那么，＂幽灵＂漏洞影响的设备范围有多广呢？
　　腾讯玄武实验室用时 4 天，研发出一款在线检测工具，经测试：哪怕是完全不同的浏览器，完全不同的操作系统，完全不同的 CPU，都可以被同一个网页触发漏洞。
　　几乎所有浏览器、所有操作系统、所有电脑、所有手机，都在＂幽灵＂漏洞的影响范围内。
　　问题来了：难道当初负责标准设计的那些人，不知道 SharedArrayBuffer 会被利用吗？
　　这个问题，我们从一份会议纪要中可以窥见一二。
　　2015 年 9 月，负责 JavaScript 标准设计的工作组，召开过一次工作会议，会议上就有相关讨论。在全面分析了安全性后，工作组还是决定把 SharedArrayBuffer 加入标准中。
　　以 Chrome 浏览器为例，我们一起来看看浏览器处理 SharedArrayBuffer 的历程：
　　2017 年 7 月，首次支持 SharedArrayBuffer 对象；
　　2018 年 1 月，因为＂幽灵＂漏洞，新版本中默认禁用 SharedArrayBuffer；
　　2018 年 7 月，重新启用 SharedArrayBuffer，但必须站点隔离；
　　2021 年 5 月，对 SharedArrayBuffer 要求跨域隔离。
　　尽管日后出现＂幽灵＂漏洞，但我们是否能说，当初工作组把 SharedArrayBuffer 加入标准的决定错了呢？
　　不能，因为这是一个符合当时实际情况的决定，我们站在未来，无法轻言对错。
　　但类似的情况，仍在不断发生。
　　前几天，安全公司 Trellix 的研究员 Kasimir Schulz，发现了一个存在 15 年、至今仍然没有被修补的 python 漏洞，有超过 35 万个项目易受影响。
　　自 2007 年 8 月首次报告以来，与该漏洞相关的技术细节一直存在可用，但直到目前，却从未收到过任何补丁，唯一提供的缓解措施，是官方 Python 的警告文档： ＂切勿在未经事先检查的情况下，从不受信任的来源提取档案＂。
　　美国科技媒体 BleepingComputer 指出，虽然没有关于该漏洞被用于攻击的报告，但它仍代表了软件供应链中的一个风险。
　　仍是在前几天，AMD工程师 K Prateek Nayak 发现，Linux 内核中有一个大约 20 年前的芯片组解决方法，现在仍不必要地被应用于现代 AMD 系统中，某些情况下，它会反过来损害现代 Zen 硬件的性能。
　　那么，＂安全左移＂与此类安全事件有什么联系呢？
　　这个词最早出现在测试行业大佬 Arthur Hicken 的博客中，他提到：Bug 的出现，85% 的缺陷产生在编码阶段，这其实是可以预期的。
　　造成缺陷的原因很多，也许是因为开发编码错误，也许是对需求理解有误，也可能是没有遵守特别的代码规范。
　　在整个研发迭代周期中，代码缺陷发现的越晚，修复的成本越会急剧增加。
　　一个真实案例是，微软发布 Windows 系统某版本时，一个 UI Bug 到生产阶段才被发现，导致数百万张光盘被迫收回并销毁，损失达千万美元，倘若该 Bug 在编码阶段就被发现，可能几秒钟就能被修复。
　　早发现、早修复、少损失，这就是当下热词＂安全左移＂的价值。
　　文 | 木子Yanni
　　嗨，这里是浅黑科技，在未来面前，我们都是孩子。
　　想看更多科技故事，欢迎戳 微信公众号：浅黑科技。