考虑到 RedHat 和其他主要业务团队正在对 bash 进行审计，并发现了除 -7169（-7186 和 -7187）之外的其他一些漏洞，链接/bin/sh到另一个 shell 是否明智？
-7186 和 -7187 都是由一位研究员 Florian Weimer 在短短几天内发现的（RedHat 自 9 月 14 日以来一直在研究 Shellshock），由 VMWare 的 Todd Sabin 独立发现。究竟还有多少潜伏者，谁也说不准。顺便说一句，我不是在谈论永久更换，只是暂停直到事情弄清楚。
要明确确定这在多大程度上可能是“谨慎的步骤”，我认为您必须对可能的替代品进行一些原始的安全研究，其中包括：
Mark 的回答表明，至少 OpenBSD 已经接受了安全审查，但我不确定程度或是否有证据支持这一点（显然，他们直到最近才对通信安全的基石（OpenSSL）进行任何审查当他们将它分叉到 LibreSSL 中时）。另一方面，我很清楚直到最近才有人费心阅读 Bash 源代码以确保安全，否则很久以前就会发现“shellshock”；整个“功能导入”的事情是一个巨大的危险信号，任何安全研究人员一看到它就会仔细检查（并希望建议删除整个功能）。但对于其他人来说，情况并不那么清楚。
不过，很明显，上述所有方法的攻击面都比 Bash 小得多。为了让攻击者控制程序，必须有一些输入通道。这些当然可以是不明显的东西，例如资源限制、系统时钟等，但它们仍然是输入；一个绝对没有输入的程序是微不足道的。Bash 中的安全设计错误在于它采用了可能不受信任的输入（任意环境变量的内容）并将它们进行复杂的处理（解析为代码）。另一方面，据我所知，上面列出的 shell 都没有对环境变量的内容进行任何处理（除了具有特定既定含义的个别变量，例如LANGand LC_*，ENV, IFS, PATH, PS1, 等）或其他输入；他们只是将内容视为传递的抽象数据。
因此，从安全设计的角度来看，即使没有审核这些替代方案，我估计它们也是比 Bash 更安全的选择。是否会保持这种情况尚不清楚。当然，Bash 现在得到了很多新的关注，而其他 shell 不太可能受到这些关注，因此我们最终可能会修复 Bash 中的大部分问题，而其他 shell 中的问题仍然未知。然后您需要考虑各种因素，例如您是否可能单独定位，在这种情况下，使用不太主流的软件可能是一种负担。
就个人而言，我在大多数地方都使用 Busybox ash。如果不出意外，ash 和 dash 都使用 bash 的 1/5 内存并且启动速度快 2-8 倍，因此从非安全角度来看，它们也是非常实用的选择。
我所知道的唯一一个经过安全问题严格检查的 shell 是 OpenBSD 的变体ksh，我不知道它是否可以安装在 Linux 系统上。除此之外，更改系统 shell 的唯一安全优势是，通过使用不太常见的 shell，更少的人会瞄准你——但同样的，更少的人会在你选择的 shell 中寻找错误。
Debian/Ubuntu 避免了大部分麻烦，因为它们有dash作为系统 shell，而 *WRT 路由器发行版这样做是因为它们使用busybox，但出于安全原因，它们都没有选择它们的 shell。在这两种情况下，都选择了备用外壳来通过减少加载时间和内存占用来提高性能。
通过用另一个产品替换产品中发现的漏洞来做出反应有点荒谬。请参阅经典的二战轰炸机生存调查问题了解原因。本质上，您正在对一个罕见且不太可能发生的事件做出反应，就好像它是 Bash 相对于其他 shell 的安全性的明确证据。
请记住，可见漏洞绝对不能说明未公开漏洞的数量以及软件中现有漏洞的数量。可能是 Bash 漏洞百出，也可能是经过审查后它完全没有漏洞。问题是在所有shell 的所有代码都经过彻底检查或更好地证明是正确的之前，没有人能够提出任何此类声明。
您最好使用有关每个项目编写的代码质量以及它们检测和修复错误以及响应关键事件的能力的指标，而不是推测少数漏洞。
Debian 和 Ubuntu 已经通过使用dash而不是bashfor来做到这一点/bin/sh。当然，这会在系统基础设施的关键部分中替代检查较少的代码库，因此很可能它具有与最近的bash问题具有同等影响的未知漏洞。