前几天看到BASH漏洞CVE-2014-6277的时候，觉得很奇怪：这么明显是故意实现的功能，怎么会有这么大的安全隐患？我不是专门搞安全的，同时我觉得这个bug虽然可能影响面很广，但并不是一个很有技术含量的使用思路。所以我把这件事搁置一旁，没有再去想。然而接下来国内外媒体的宣传、安全专家的联合建议、饭后聊天……大家都认为BASH的这个bug是个大bug。很多人还在为此幸灾乐祸……但是我并没有从各种评论中找到我的问题的答案。然而，当我看到这篇文章时，我不得不同意作者的观点：这根本不是BASH的错误！所以我在这里翻译原文，希望能带来一些思考。也许我们今天看到的一个愚蠢的错误，在历史的某一天，是一个有意的神奇功能。或许此时此刻我们应该思考的不仅仅是bug或安全风险本身，而是在软件项目活动中如何有效保证某个特性不会成为bug，这是一个具有工程与安全双重特征的活动。创建。那么什么是标准化和文档化，真的不是纸上谈兵！但话虽如此，我仍然坚信：“少即是多！”（道路很简单）”也许功能越少意味着错误越少？————TranslationSeparator————我想讨论一下，这个BASH安全问题实际上并不是一个错误。这显然是一个功能。诚然，这是一个错误实现和误用的功能。虽然它仍然是一个功能。问题是它是25年前设计的。Apache直到五年后才出现！是的，那时候有互联网，但它是一个紧密联系的小圈子.当时根本没有考虑到互联网软件和协议的安全性，更不用说开发shell等程序的时候了。一种非正式且通用的方式。在创建新的子进程时，可以使用环境变量将某些数据从父进程传递给子进程。在BASH的情况下，这是一个必需的特性，在BASH父进程中定义的函数可以传递给子进程并得到定义。使用环境变量传递这些函数的定义是很自然的事情。环境变量传递的函数定义后可以执行任何命令，是略微超出设计规范的实现。由于在大多数情况下BASH程序将要传递的函数存储在环境变量中，因此通常没有其他命令。但是，在设计BASH时，用户是否可以向此类环境变量添加命令被认为是一个特性。无论如何，子进程的行为取决于配置此环境变量的用户，因此不存在安全问题。此功能记录在导出内置函数的-f选项中。函数定义后以“(){”开头的环境变量可以包含更多命令的实现细节没有记录，但仍然可以认为是一个特性。问题是五年后，正在开发的新软件使用BASH作为子进程，并且仍然使用环境变量来传递数据（Apache、DHCP等）。不幸的是，有些数据不再来自受信任的本地系统用户（译注：典型的物理安全信任），而是来自这个星球上互联网上的任何用户或程序。同时，未记录（但已发布）的BASH功能被遗忘了。关于UNIX系统，环境变量可以由父进程控制是一个古老的想法，输入数据应该有效是一个更古老、更普遍的想法。据推测，像Apache这样的程序会对环境变量进行适当的过滤。但不幸的是，它们无法正确验证输入数据，因为它们没有考虑到以“(){”开头的数据将由它们生成的BASH子进程解释。如果这里有错误，那不是在BASH中，而是在Apache和其他面向网络的程序中，没有正确验证和控制它们传递给BASH的数据。也就是说，BASH有其自身的问题，就像大多数软件一样：它缺少规范文档并且具有未记录的功能。我们的问题不是BASH错误，它基本上是一个类似的Ariane5错误：使用规范已过时的早期系统的模块。在这种特殊情况下，使用过时规范的原因似乎是没有记录，也没有相关实现细节的文档。但另一方面，这是免费软件，因此查看源代码就像找鼻子一样容易。在没有规范和文档的情况下重用模块时，检查源代码实现应该是一个标准程序，但显然Apache或DHCP的开发人员并没有这样做。bug还在，就像阿丽亚娜5的bug不是阿丽亚娜4的bug一样！原文来自：http://mikespook.com/2014/09/not-a-bash-bug/
