bashを別のシェルに置き換えることは賢明なステップですか？
RedHatおよびビジネスの他の主要チームがbashで監査を実施していて、-7169（-7186および-7187）以外のいくつかの脆弱性を発見したことを考えると、/bin/sh別のシェルに？
-7186と-7187の両方がたった数日で1人の研究者（Florian Weimer）によって発見され（RedHatは9月14日からShellshockに取り組んでいます）、VMWareのTodd Sabinが独自に発見しました。誰が推測しているのでしょうか。ちなみに、私は永久交換について話しているのではなく、物事が明らかになるまで一時停止するだけです。
これが「賢明なステップ」であるかどうかを明確に判断するには、考えられる置き換えについて、次のような独自のセキュリティ調査を行う必要があると思います。
- Debianのダッシュ
- OpenBSDのksh
- Busyboxアッシュ
- MirBSD/MirOS mksh
- ...そして確かに他の
Markの回答は、少なくともOpenBSDはすでにセキュリティの調査を受けていることを示唆していますが、これまでの範囲や、これを裏付ける証拠があるかどうかはわかりません（明らかに、最近まで通信セキュリティ（OpenSSL）の基礎に調査を適用していませんでした）。 LibreSSLにフォークしたとき）。一方で、最近までセキュリティのためにBashのソースを読むことに煩わされていなかったこと、または「シェルショック」がずっと前に発見されていたことは、私にはかなり明らかです。 「関数のインポート」の全体は非常に重大な問題であり、セキュリティ研究者は、それを見つけたらすぐに精査します（そして機能全体を削除することをお勧めします）。しかし、他の人にとっては、それほど明確ではありません。
しかし、明らかなことは、上記のすべての攻撃面がBashよりもはるかに小さいことです。攻撃者がプログラムを制御するには、何らかの入力チャネルが必要です。もちろん、これらはリソース制限、システムクロックなどの自明ではないものにすることもできますが、それでも入力です。入力がまったくないプログラムは、明らかに脆弱ではありません。 Bashのセキュリティ設計バグは、信頼できない可能性のある入力（任意の環境変数のcontents）を受け取り、それらを複雑な処理（コードとして解析）していることです。一方、私が知る限り、上記のシェルは環境変数の内容を処理しません（LANGやLC_*などの特定の確立された意味を持つ個々のシェルを除く） 、ENV、IFS、PATH、PS1など）またはその他の入力。それらは通過する抽象的なデータとして内容を扱うだけです。
したがって、セキュリティ設計の観点から、これらの代替案を監査しなくても、Bashよりも安全な選択肢であると推定します。それがケースに残るかどうかは明らかではありません。確かに、現在Bashは多くの新しい注目を集めていますが、他のシェルはこれを受け取る可能性が低いため、他のシェルの問題は不明のまま、Bashのほとんどの問題が修正される可能性があります。次に、個別にターゲットにする可能性が高いかどうかなど、考慮すべきさまざまな要素があります。
個人的には、ほとんどの場所でBusybox ashを使用しています。他に何もない場合、ashとdashはどちらもbashの約1/5のメモリを使用し、2-8倍速く起動するため、セキュリティ以外の観点からも非常に実用的な選択肢です。
セキュリティ問題について真剣に検査されていることを知っている唯一のシェルは、OpenBSDのバリアントkshであり、Linuxシステムにインストールできるかどうかはわかりません。それ以外に、システムシェルを変更することによる唯一のセキュリティ上の利点は、あまり一般的ではないシェルを使用することにより、ターゲットとする人が少なくなることです。しかし、同じように、選択したシェルのバグを探す人が少なくなります。
Debian/Ubuntuは、システムシェルとしてdashがあり、* WRTルーターディストリビューションはbusyboxを使用しているため、ほとんどの問題を回避しましたが、セキュリティ上の理由からシェルを選択しませんでした。どちらの場合も、読み込み時間とメモリフットプリントを削減してパフォーマンスを向上させるために、代替シェルが選択されました。
製品に見られる脆弱性を別のものに置き換えることで対応するのは少しばかげています。理由については、古典的な WW2爆撃機生存調査問題 を参照してください。基本的に、あなたは他のシェルのセキュリティに対するBashのセキュリティの決定的な証拠であるかのように、まれでありそうにない1つのインシデントに反応しています。
visibleエクスプロイトは、undisclosedの数やソフトウェアの既存の脆弱性の数についてはまったく何も言わないことに注意してください。 Bashにはバグが多く含まれている可能性があります。または、調査の結果、脆弱性が完全になくなっている可能性があります。問題は、allシェルのコードがall完全に調査されるか、さらに良くなるまで、誰もそのような主張をすることができないということです正しいことが証明されました。
少数の脆弱性を推測するのではなく、各プロジェクトによって記述されているコードの品質と、バグを検出して修正し、重大なインシデントに対応する能力に関するメトリックスを使用するほうがよいでしょう。
DebianとUbuntuは、/bin/shにdashの代わりにbashを使用してこれをすでに行っています。もちろん、これはシステムインフラストラクチャの主要な部分で検査されていないコードベースを代用するため、最近のbashの問題に同等の影響を与える未知の脆弱性があることは明らかです。
この脆弱性に対して行うことはすべて、実際の潜在的なリスクベクトルの分析に基づく必要があります。シェルをインタラクティブシェルとして使用するだけで、極端な場合でも、このバグによるリスクはまったくありません。
このバグが存在するのは、シェルの呼び出しで見られるように、一部のプログラムが悪意のある当事者が環境変数の内容を制御できる場合のみです。たとえば、環境変数をリクエストからのユーザーエージェントヘッダーの値に設定し、サニタイズしないWebサーバー。このようなサービスを実行する場合、このバグの有無にかかわらず、可能な限り最も単純なシェルを使用することは理にかなっています。シェルへのアクセスが少ないほど、セキュリティにさらされる可能性のある場所が少なくなります。もちろん、Webサーバーが刑務所で実行されていて、この質問全体が気にならなかった方がよいでしょう。したがって、サンドボックス化されていない環境でシェルを起動するWebサーバーなどを実行する必要がある場合は、利用可能な最も単純なシェルを実行して露出を減らすのが理にかなっています。