Linux 用户今天又得到了一个“惊喜”！ Red Hat 安全团队在 Linux 中广泛使用的 Bash shell 中发现了一个隐晦而危险的安全漏洞。该漏洞被称作“Bash Bug”或“Shellshock”。

当用户正常访问，该漏洞允许攻击者的代码像在 shell 中一样执行，这就为各种各样的攻击打开了方便之门。而且，更糟糕的是该漏洞已经在 Linux 中存在很久了，所以修补某个 Linux 机器很容易，但是要全部修补，几乎不可能完成。

Red Hat 和 Fedora 已经发布了针对该漏洞的修补程序。该漏洞也会影响 OS X，不过苹果公司尚未发布正式的修补程序。

这个 Bash 漏洞可能比 Heartbleed 更危险。
— — Robert Graham （@ErrataRob） 2014 年 9 月 24 日

Red Hat 的 Errata Security 团队的 Robert David Graham 比较了这个安全漏洞和 Heartbleed 的风险，该漏洞分布更广泛，有可能对系统安全带来长期影响。Graham 在一篇博客文章中写道，“有大量的软件以某种方式与 shell 交互，我们没有办法列举受到该漏洞影响的所有软件。”据 Verge 得到的消息，Berkeley ICSI 的研究员Nicholas Weaver 也悲观的同意这个说法：“它很隐晦、很可怕，并且将会伴随我们多年。”

网络安全公司Rapid7工程部经理 Tod Beardsley 警告称，Bash漏洞的严重级别为“10”，意味着它对用户电脑的威胁最大。Bash漏洞的利用复杂度级别为“低”，意味着黑客可以相对轻松地利用它发动攻击。

另有网络安全公司Trail of Bits的CEO Dan Guido表示，“Heartbleed”漏洞能够允许黑客监控用户电脑，但不会取得控制权。而利用Bash漏洞的方法也更简单——只需要剪切和粘贴一行代码即可。

据称，谷歌安全研究员 Tavis Ormandy 在Twitter上表示，Linux系统提供商推出的补丁似乎“并不完整”，这引发了几位安全专家的担忧。

已知受到影响的 Linux 发行版和软件包括：

• Ubuntu Ubuntu Linux 12.04 LTS i386/amd64
• Ubuntu Ubuntu Linux 10.04 sparc/powerpc/i386/ARM/amd64
• GNU GNU bash 3.1.4/3.0.16/4.2/4.1/4.0 RC1/4.0/3.2.48/3.2/3.00.0(2)/3.0
• Debian Linux 6.0 sparc/s390/powerpc/mips/ia-64/ia-32/arm/amd64
• CentOS CentOS 5

更多技术细节，可以参考：

• https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
• https://www.us-cert.gov/ncas/current-activity/2014/09/24/Bourne-Again-Shell-Bash-Remote-Code-Execution-Vulnerability

如果你的公司依赖像OpenSSL这样的开源软件，是时候主动点了。

心脏流血漏洞让开源社区如芒在背。

ComputerWorld的Richi Jennings 抨击说“又一个非常可怕的开源失败。”（他是要做标题党么？）ZDNet的Steven J. Vaughan-Nichols不像是作秀反开源，却仍旧将心脏流血漏洞渲染为“开源软件的最遭时刻”。而最后，ZDNet的Chris Duckett则务实地倡议：“商业公司（应该）筹集资金来避免心脏流血再次发生。”

而实际上，企业资金并不是解决心脏流血事件的最终答案 。你才是！

想要避免开源失败的公司应该不仅仅是开源软件的用户，还要是贡献者。

贡献者乘坐头等舱

贡献者能够引导特定的项目。他们占据主动，而不是被动接受。大多数企业缺乏资源参与他们所使用的所有开源项目，但每家公司都可以资助给那些真正关系到他们的项目。并且资助得越多，得到的好处越大。

开源就是一个不断给予的礼物，尤其是给予那些对开源反哺的人们。

我在MongoDB的同事Adam Comerford让这点更有说服力：如果你看看第一批得知Heartbleed漏洞的时间线，那些第一批得知的（如谷歌）有一个相当大的优势。如Comford所说的，这些公司有一个显著的优势就是他们可以在bug还未大规模传开的时候率先采取措施保护他们的系统。

鉴于早期了解像Heartbleed之类问题的优势，Comerford问：“我如何确保我在这类问题的早期通知列表里面？”

如果你依赖于专有软件，你有一个答案：向卖方支付大量的金钱，并希望他适时地响应。但是，如果你正在使用开源软件，有一个更多选择： “要么有大量的员工给[开源项目]做贡献 ，或者...有认识主要贡献者的员工（我们可以找找，他们大多也会贡献其他开源软件项目，像其他的极客和呆瓜一样。“

Comerford断言说，好处不止这样：

这有很多好处 - 除了让问题及早通知，让手头上的专家来应付这些棘手的更新，以评估你的风险，甚至可能在公众知道之前内部解决问题。在确定项目的方向上你还可以得到重视的回馈，可以影响到关键特性的优先级。最终，你会得到社区的善意，使产品变得更好，并有可能成为其它的聪明贡献者的工作目标。

换句话说，参与进来。成员有特权，主要的特权可能就是信息。

选择在哪贡献

同样，没有一家公司有足够的资源来有效地促进所有它所使用的项目，这就是为什么Comerford建议对关键项目上这么做的原因：

如果你要人们列出在企业中所有开源关键技术，你可能会得到一张很长的名单。然后，告诉他们，他们将必须清点人工和预算来支持清单上的每一种技术的话（并验证它） - 它可能会迅速缩水。

如果你是一个AMD那样的芯片公司，给Linux内核贡献基本驱动程序和其他代码很可能是强制性的。给LibreOffice贡献可能不是。或者，如果你判断你的未来在Hadoop上进行深层数据分析，你应该贡献Hadoop，即使你依旧免费使用OpenSSL社区的成果。比如Dish Networks公司，它的 CIO告诉上周在开放商业会上的人们，他们正在将重要的数据从关系型数据库转到Apache的Kafka，那他最好研究Kafka的代码，即使他不贡献给Apache HTTP服务器项目。

每家公司都有其优先级，以及这些优先级应该以严肃的承诺而确立。

这是确保这些项目安全的一部分办法。而另一部分，它是一种形成影响力指引的方式。但同时，红帽公司CEOJim Whitehurst早在2008年声明，它是显著减少IT花费的办法：

今天编写的绝大多数软件是企业编写的，不得转售。并且绝大多数是从来没有真正使用过。IT软件开发中的浪费是巨大的....最终，开源给全世界的客户提供价值，我们不仅需要让我们的客户作为开源产品的用户，而且真正加入开源和参与在开发社区。

Comerford坚持认为：“如果我在业务中使用开源软件，我应该雇开发人员来积极给软件做贡献，如果他们自己不是核心开发者，那就雇佣核心开发者。 ”这是充分利用开源软件的关键：给它做贡献，不只是使用它。

via: http://readwrite.com/2014/05/14/heartbleed-open-source-contribution-users

译者：geekpi 校对：wxy

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