TranslateProject/translated/The Debian OpenSSL Bug- Backdoor or Security Accident.md
2013-10-14 10:24:54 +08:00

5.7 KiB
Raw Blame History

Debian OpenSSL Bug - 后门还是安全事故?

周一Ed 写了篇文章《软件透明度》1,主旨是如果软件开发的过程是透明的,那么软件本身对恶意的后门(无心的安全漏洞)更具抵抗性。 软件透明的因素包括公开源代码,可以获取一个项目的追踪议题,以及允许参与内部开发者会议。他提到一种情况,在这儿我想详细讨论一下: 2008年Debian项目一个流行的用于web服务器的linux发行版宣称2Debian中OpenSSL3的伪随机数生成器遭到破解,已经不安全了。

首先了解一些背景信息伪随机数生成器PRNG就是一个程序假定代号为F。给定一个随机种子s通过F(s)进行处理后, 会得到一个长的比特流。如果我和你都使用同样的种子s两个人会得到同样的比特流。但是如果我随机选择一个s也不告诉你s是什么 你根本不能够推测F(s)的结果如你所知F(s)也是随机的。OpenSSL中的PRNG试图从系统中抓取不可预测的信息"熵",比如当前进程ID 或者很有可能是不同的内存数据比如未初始化的内存该内存可能或者就是由其它一些进程控制等等。把这些东西转换成种子s 经F(s)处理,就会得到随机比特流。

2006年为了解决一条从一个查找软件内存存取bug的工具5生成的警告4一名Debian维护者决定注释掉6OpenSSL PRNG里的两行代码7。 结果这两行代码非常重要代码负责抓取几乎所有的不可预测的熵抓取的熵会作为OpenSSL PRNG的种子。没有这些代码 PRNG只有总共32,767个选择可作为种子因而也就是说只有这么多的选择可用于F(s)进行处理。

很多依赖于OpenSSL随机数生成器的程序其实并不拥有那么多的随机选择但是他们原以为会有那么多的。 一个这样的程序要为SSL安全网络浏览和SSH安全远程登录生成秘钥。问题的关键在于这些秘钥必须是随机的如果你可以猜到我的秘钥 你就可以破解我使用该秘钥保护的任何东西。这意味着你有能力读取加密的通讯信息,登录到远程服务器8,或者伪造看起来似乎是真实的信息9。 这个漏洞是2006年第一次引入而且进入到Ubuntu中10。漏洞影响到数以千计的服务器而且 存在了很长一段时间11,因为只是给受影响的服务器打补丁还不足以解决问题,必须替换掉任何在漏洞存在情况下生成的秘钥。

顺便说一句,为伪随机数生成器寻找熵是个著名12的难题13。事实上,在今天来看要解决这个问题依然是个巨大的挑战。随机错误难以检测, 因为当你盯着输出看,每次运行程序结果都不一样,就像随机的一样。弱随机性很难定位,但是它可以使(貌似)安全的加密系统失效。 依然如此Debian中的那个漏洞一经发现在安全界15就常常被当做笑柄16

这是个后门,故意设置的吗?似乎不大可能。Kurt Roeckx代码维护者后来成为Debian项目的主管。显然他是个可靠的家伙 不是为了故意设置漏洞而由NSA伪造出来的身份。想进入Debian项目组的核心需要做出巨大的努力那真是出了名的难进。 这样看来,错误根本不是自己冒出来,而是一系列失误导致的,而且后果严重。

漏洞确实是在一个透明的环境下引入的。所做的任何一件事都是公开的。但是漏洞就在那儿,而且呆了相当长一段时间。 部分原因在于,正因为所有的事情都是透明的,才导致极大的混乱,人们对那个显而易见的漏洞也都没太在意。 另外,也因为漏洞本身太过微妙。让修改带来的影响随便给谁看都能那么明显,这也不是设计该系统的目的。

这是否意味着软件透明没什么益处? 我可不这么认为。许多人都赞同透明软件要比不透明软件更安全。 但是这也并不表示漏洞不会产生,或者认为有其他人都看着呢而我们自己就可以掉以轻心。

至少,多年以后,透明可以让我们回想起,究竟是什么导致的那个漏洞,原来是工程上的纰漏而非人为破坏。

via: https://freedom-to-tinker.com/blog/kroll/software-transparency-debian-openssl-bug/

本文由 LCTT 原创翻译,Linux中国 荣誉推出

译者:l3b2w1 校对:校对者ID