Shellshock（CVE-2014-6271/7169）バグはいつ紹介されましたか？このバグを完全に修正したパッチは何ですか？

長い話を短く

Shellshockの脆弱性が完全に修正されました。

• bash-2.05bブランチ：2.05b.10以上（パッチ10を含む）
• bash-3.0ブランチ：3.0.19以上（パッチ19を含む）
• bash-3.1ブランチ：3.1.20以上（パッチ20を含む）
• bash-3.2ブランチ：3.2.54以上（パッチ54を含む）
• bash-4.0ブランチ：4.0.41以上（パッチ41を含む）
• bash-4.1ブランチ：4.1.14以上（パッチ14を含む）
• bash-4.2ブランチ：4.2.50以上（パッチ50を含む）
• bash-4.3ブランチ：4.3.27以上（パッチ27を含む）

Bashに以前のバージョンが表示されている場合は、オペレーティングシステムのベンダーから直接パッチを適用できるため、確認するのが最善です。

場合:

env xx='() { echo vulnerable; }' bash -c xx

「脆弱性」を見せても依然として脆弱です。これは唯一の関連テストです（bashパーサーがまだ公開されているかどうか）。どの環境変数）。

詳細。

^{このバグは、1989年8月5日にBrian Foxによって導入されたエクスポート/インポート機能の初期実装に存在し、セキュリティの前に}bashが広く使用される前の約1ヶ月後にbash-1.03で最初にリリースされました。これは大きな関心事であり、HTTPとWebまたはLinuxも存在します。

~から1.05の変更履歴:

Fri Sep  1 18:52:08 1989  Brian Fox  (bfox at aurel)

       * readline.c: rl_insert ().  Optimized for large amounts
         of typeahead.  Insert all insertable characters at once.

       * I update this too irregularly.
         Released 1.03.
[...]
Sat Aug  5 08:32:05 1989  Brian Fox  (bfox at aurel)

       * variables.c: make_var_array (), initialize_shell_variables ()
         Added exporting of functions.

いくつかの議論GNU バッシュエラーそしてcomp.unix.問題この機能はその頃にも言及されました。

それがどのようにそこに到達したかを理解するのは簡単です。

bash は環境変数に関数をエクスポートします。

foo=() {
  code
}

インポートするときにやるべきことは、=それを解釈するために空白に変更するだけです。ただし、盲目的に解釈してはいけません。

bashもう1つの問題は、（Bourneシェルとは異なり）スカラー変数と関数の名前空間が異なることです。実は、あなたが持っているなら

foo() { echo bar; }; export -f foo
export foo=bar

bashどちらも環境に喜んでいます（たとえば、同じ変数名を持つ項目）、多くのツール（多くのシェルを含む）はそれを伝播しません。

一部の人々は、BASH_環境変数がbashにのみ関連しているため、bashはそのために名前空間接頭辞を使用する必要があると思います。同様の機能を持つプレフィックスをrc使用してください。fn_

これを達成するより良い方法は、エクスポートされたすべての変数の定義を変数に入れることです。たとえば、次のようになります。

BASH_FUNCDEFS='f1() { echo foo;}
  f2() { echo bar;}...'

これはまだ整理が必要ですが、少なくとももはや$BASH_ENV簡単に悪用することはできません$SHELLOPTS...

bash関数定義以外の内容が解釈されないようにするパッチがあります（https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00081.html）は、さまざまなLinuxディストリビューションに適用されるすべてのセキュリティアップデートの1つです。

しかし、bashはまだその中にあるコードを解釈するので、ソルバーのすべてのバグが悪用される可能性があります。そのようなエラー発見されました（CVE-2014-7169）ですが、その影響ははるかに小さいです。それでもうすぐパッチがある予定です。

bashがどの変数でもコードを解釈するのを防ぐ強化された修正があるまで（たとえば、上記のBASH_FUNCDEFS方法を使用する）、私たちはbashパーサーのバグの影響を受けないと確信できません。私はそのような強化された修正がすぐにリリースされると信じています。

2014-09-28 編集

パーサーでも2つのバグが見つかりました（CVE-2014-718{6,7}）（ほとんどのシェルは特別な場合に備えてパーサーにバグがなければならず、パーサーがこれを実行しないと何もしません）。信頼できないデータにさらされず）。

3つのバグ7169、7186、7187がすべて後続のパッチで修正されましたが、Red Hatはまだハードフィックスを進めています。パッチでは、機能をBASH_FUNC_myfunc()やや先制的なChet設計決定という変数にエクスポートするように動作を変更しました。

後でチェット公式アップストリームbashパッチで修正をリリースします。。

この強化パッチまたはそのバリエーションは、ほとんどの主要なLinuxディストリビューションとApple OS / Xで利用可能になりました。

これで、パーサーの他の2つの脆弱性を含む、このベクトルを介してパーサーの任意の環境変数を悪用することに関する懸念がなくなりました（CVE-2014-627{7,8}）。後で判明しました。投稿者：Michał Zalewski（CVE-2014-6278はCVE-2014-6271と同じくらい危険です）幸いなことに、ほとんどの人は強化パッチをインストールする時間があります。

パーサーのバグも修正されますが、パーサーは信頼できない入力にさらされないため、これ以上大きな問題にはなりません。

セキュリティの脆弱性が修正されましたが、この領域にはいくつかの変更がある可能性があります。 CVE-2014-6271の初期修正は、その名前を含む関数のインポートを中断したため、以前のバージョンとの互換性が損なわれ.ました:。/これはまだbashとして宣言できますが、これは一貫性のない動作を引き起こします。その名前を.含む機能が一般的に使用されるため、:パッチは少なくとも環境で機能を許可するように戻る可能性が高くなります。

もっと早く調べてみてはいかがでしょうか？

これは私も知りたいことです。いくつかの説明を提供できます。

まず、セキュリティ研究者（私はプロのセキュリティ研究者ではありません）が特にbashの脆弱性を探していた場合は、おそらく発見したでしょう。

たとえば、私がセキュリティ研究者である場合、私のアプローチは次のようになります。

1. bash入力をどこで受け取り、どのように処理するかを確認してください。そして環境も一目でわかります。
2. bash通訳者が呼び出される場所とデータを確認してください。今回も目立つ。
3. 輸入エクスポート機能setuid / setgidのときに無効になる機能の1つbashなので、より明確になります。

今私は誰かbash（通訳者）を脅威として見たり、脅威がそのように生成される可能性があると疑います。

インタプリタは、bash信頼できない入力を処理するためのものではありません。

シェルスクリプト（通訳者ではなく）セキュリティの観点から綿密に調査されることが多い。シェル構文は非常に厄介で信頼できるスクリプトを書くことに多くの注意があります（私や他の人がスプリット+グローブ演算子に言及したことを見たことがあるか、変数を引用する必要があるのはなぜですか？）処理中のセキュリティ抜け穴を見つけるのはとても難しいです。スクリプト。信頼できないデータ。

これがCGIシェルスクリプトを書いてはいけないか、またはほとんどのUnicesでsetuidスクリプトが無効になっていることをよく聞く理由です。または、グローバルに書き込み可能なディレクトリにあるファイルを処理するときは、慎重に注意する必要があります（参照：CVE-2011-0441例えば）。

フォーカスはインタプリタではなくシェルスクリプトにあります。

evalユーザー提供のファイルから呼び出して（解釈用のシェルコードとして外部データを提供する）、シェルインタプリタを信頼できないデータに公開する可能性がありますが、悪用するために.脆弱性は必要ありません。bash明らかに、解釈のために生データをシェルに渡すと、シェルはそれを解釈します。

したがって、シェルは信頼できるコンテキストで呼び出されます。解釈する固定スクリプトを提供し、通常は（信頼できるスクリプトを作成するのは非常に困難です）、処理する固定データを提供します。

たとえば、Web コンテキストでは、シェルは次のように呼び出すことができます。

popen("sendmail -oi -t", "w");

何が間違っている可能性がありますか？問題が発生した場合は、シェルのコマンドライン自体を解析する方法や、シェルに追加のデータを供給する方法ではなく、sendmailに供給されるデータに関するものです。シェルに渡された環境変数を考慮する理由はありません。これにより、名前が「HTTP_」で始まるすべての環境変数は、よく知られているCGI環境変数であるか、シェルまたはsendmailとは関係がないことがSERVER_PROTOCOLわかります。QUERYSTRING

setuid / setgidを実行したりsudoを介して実行したりするなど、権限エスカレーションコンテキストでは環境が考慮されることが多く、過去にもシェル自体ではなく権限を上昇させる項目に多くの脆弱性がありました。sudo（例えば参照CVE-2011-3628）。

たとえば、bashsetuidによって呼び出された場合、またはsetuidコマンド（mountヘルパープログラムの呼び出しなど）を介して呼び出されると、環境は信頼されません。特にエクスポートされた関数は無視されます。

sudoクリーンな環境の実行：デフォルトでは、ホワイトリストに含まれている環境を除くすべての環境が一覧表示され、そうしないように設定した場合は、シェルや他の方法（たとえば、PS4... BASH_ENV）SHELLOPTSに影響を与えることが知られているいくつかの環境が一覧表示されます。また、環境変数をブラックリストに追加します。コンテンツ（これがCVE-2014-6271が()権限の昇格を許可しない理由ですsudo）。

ただし、これは環境を信頼できないコンテキストにも当てはまります。つまり、そのコンテキストでは、悪意のあるユーザーが名前と値を持つすべての変数を設定できる可能性があります。これは、Webサーバー/ sshまたは環境が制御されるCVE-2014-6271を使用するすべてのベクトルには適用されません（少なくとも環境変数の名前は制御されます...）。

同じ変数をブロックすることは重要ですecho="() { evil; }"が、シェルスクリプトやコマンドラインがそれをコマンドとして呼び出さないHTTP_FOO="() { evil; }"ため、そうではありません。 apache2はOR変数をHTTP_FOO設定しません。echoBASH_ENV

それは明らかです一部状況によっては、環境変数をブラックリストに追加する必要がある場合があります。名前しかし、自分の状況に応じてブラックリストに登るべきだと思う人は誰もいません。コンテンツ（とは別にsudo）。つまり、任意の環境変数がコード挿入のベクトルであると考える人は誰もいません。

機能が追加されたときに行われた広範なテストでこれを捉えることができたかどうかについては、その可能性が低いと思います。

テストするとき特徴、機能をテストします。この機能はうまく機能します。ある呼び出しから関数をエクスポートすると、bash別の呼び出しからインポートできます。非常に徹底的なテストでは、同じ名前の変数と関数をエクスポートしたり、関数をエクスポートしたときとは異なるロケールにインポートしたりすると問題が発生する可能性があります。

ただし、脆弱性を見つけるために機能テストを実行する必要はありません。セキュリティの側面が主な焦点であるべきであり、機能をテストするのではなく、メカニズムとそれが悪用される可能性がある方法をテストする必要があります。

これは開発者（特に1989年）がよく考えるものではなく、シェル開発者は自分のソフトウェアがネットワークによって悪用される可能性がないと考えるかもしれません。