web-dev-qa-db-ja.com

Shellshock（CVE-2014-6271 / 7169）バグが導入されたのはいつですか？それを完全に修正するパッチは何ですか？

バグに関するいくつかのコンテキスト： CVE-2014-6271

Bashは、シェル変数だけでなく、シェル関数を他のbashインスタンスに、プロセス環境を介して（間接的な）子プロセスにエクスポートすることもできます。現在のbashバージョンは、関数名で指定された環境変数と、変数値の「（）{」で始まる関数定義を使用して、環境全体に関数定義を伝播します。この脆弱性は、関数定義の処理後にbashが停止しないために発生します。関数の定義に従って、引き続きシェルコマンドを解析および実行します。たとえば、環境変数の設定

  VAR=() { ignored; }; /bin/id

環境がbashプロセスにインポートされると、/ bin/idが実行されます。

出典： http://seclists.org/oss-sec/2014/q3/65

バグが導入されたのはいつで、それを完全に修正するパッチは何ですか？（ CVE-2014-7169 を参照）

CVEに記載されている脆弱性のあるバージョン（初期）（3. {0..2}および4. {0..3}）を超えるものは何ですか？

バグのあるソースコードが他のプロジェクトで再利用されていますか？

追加情報が望ましい。

関連： env x = '（）{：;};コマンド' bashは何をし、なぜそれが安全でないのですか？

bashsecurityshellshock
122
Deer Hunter

TL; DR

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が古いバージョンを示している場合、OSベンダーがまだそれをパッチした可能性があるため、確認することをお勧めします。

次の場合：

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

「脆弱」と表示されていても、まだ脆弱です。これが関連する唯一のテストです（bashパーサーがany環境変数のコードにまだ公開されているかどうか）。

詳細。

バグは5で導入された関数のエクスポート/インポートの初期実装にありました番目 1989年8月にBrian Foxによってリリースされ、約1か月後にbashがそれほど普及していなかった時期にbash-1.03で最初にリリースされました。

1.05のChangeLog から：

_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.bash.bug および comp.unix.questions でのいくつかの議論でも機能について言及しています。

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

bashは次のような環境変数で関数をエクスポートします

_foo=() {
  code
}
_

そして、インポート時に、_=_をスペースで置き換えて解釈するだけです。盲目的に解釈しないようにしてください。

また、bashでは（Bourne Shellとは対照的に）、スカラー変数と関数の名前空間が異なるという点でも問題があります。実際に

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

bashは、両方を環境に入れます（同じ変数名のエントリがあります）が、多くのツール（多くのシェルを含む）はそれらを伝播しません。

また、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ディストリビューションからのすべてのセキュリティアップデートに適用されたものです。

ただし、bashはそこにあるコードを引き続き解釈するため、インタープリターのバグが悪用される可能性があります。そのようなバグの1つ すでに検出されています （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}）を含むそのベクターを介してパーサーを悪用する任意のenv varの懸念が埋められます 後で公開されました MichałZalewski（ CVE-2014-6278はCVE-2014-6271とほぼ同じくらい悪い）多くの人が強化パッチをインストールする時間があった後、ありがたいことに

パーサーのバグも修正されますが、パーサーが信頼できない入力にそれほど簡単にさらされなくなったため、これらのバグはそれほど問題ではなくなりました。

セキュリティの脆弱性は修正されましたが、その領域でいくつかの変更が見られる可能性があることに注意してください。 CVE-2014-6271の最初の修正では、_._または_:_または_/_が名前に含まれている関数のインポートが停止するという下位互換性が失われました。これらはまだbashで宣言できますが、これは一貫性のない動作になります。名前に_._および_:_が含まれる関数が一般的に使用されるため、パッチは少なくとも環境からのものを受け入れて復元される可能性があります。

なぜそれが以前に見つからなかったのですか？

それもまた疑問に思いました。私はいくつかの説明を提供できます。

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

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

  1. bashがどこから入力を取得し、何を使用しているかを確認します。そして、環境は明白なものです。
  2. bashインタープリターが呼び出される場所とデータを確認します。再び、それは際立つでしょう。
  3. エクスポートされた関数のインポートは、bashがsetuid/setgidである場合に無効になる機能の1つであり、これにより、より見やすい場所になります。

さて、bash（インタープリター）を脅威と見なす人は誰もいないのではないかと思います。

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

シェルscripts（インタプリタではない）は、セキュリティの観点からよく見られます。シェル構文は非常に扱いにくく、信頼性の高いスクリプトを書くには多くの警告があります（私や他の人がsplit + glob演算子について言及したり、たとえば変数を引用する必要があるのはなぜですか？）、処理するスクリプトにセキュリティの脆弱性を見つけることはよくある信頼できないデータ。

そのため、CGIシェルスクリプトを記述すべきではない、またはほとんどのUnicesではsetuidスクリプトが無効になっているとよく耳にします。または、誰でも書き込み可能なディレクトリのファイルを処理するときは、特に注意する必要があります（たとえば CVE-2011-0441 を参照）。

その焦点は、インタプリタではなく、シェルスクリプトにあります。

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

したがって、シェルは信頼されたコンテキストで呼び出されます。解釈する固定スクリプトが与えられ、処理する固定データが（信頼できるスクリプトを書くのは非常に難しいため）多くの場合そうです。

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

_popen("sendmail -oi -t", "w");
_

何が問題になるのでしょうか？何か問題が想定される場合、それはそのsendmailに送られるデータに関するものであり、シェルのコマンドライン自体がどのように解析されるのか、またはそのシェルにどのような追加のデータが送られるのかではありません。そのシェルに渡される環境変数を検討する理由はありません。そうすると、名前が「HTTP_」で始まるすべてのenv変数、または_SERVER_PROTOCOL_やQUERYSTRINGなどのよく知られたCGI env変数であり、シェルやsendmailは何の関係もありません。

Setuid/setgidを実行するときやSudoを介して実行するときなどの特権昇格コンテキストでは、環境が一般に考慮され、過去にも多くの脆弱性がありました。これも、シェル自体ではなく、Sudoなどの特権を昇格させるものに対してです（たとえば、 CVE-2011-3628 ）。

たとえば、bashは、setuidコマンドまたはsetuidコマンドによって呼び出されたときに環境を信頼しません（ヘルパーを呼び出すインスタンスについてはmountと考えてください）。特に、エクスポートされた関数は無視されます。

Sudoは環境をクリーンアップします。ホワイトリストを除くすべてのデフォルトで、少なくとも構成されていない場合は、シェルまたは別のシェルに影響を与えることがわかっているいくつかのブラックリスト（_PS4_、_BASH_ENV_、 SHELLOPTS...）。また、contentが_()_で始まる環境変数をブラックリストに登録します（これが、CVE-2014-6271がSudoによる特権昇格を許可しない理由です）。

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

_HTTP_FOO_はシェルスクリプトまたはコマンドラインからコマンドとして呼び出されないため、echo="() { evil; }"ではなくHTTP_FOO="() { evil; }"のような変数をブロックすることが重要です。また、Apache2がechoまたは_BASH_ENV_変数を設定することは決してありません。

some環境変数は、nameに基づいて一部のコンテキストでブラックリストに登録する必要があることは明らかですが、誰もがそうする必要があるとは考えていませんcontentに基づいてブラックリストに登録されています（Sudoを除く）。あるいは、言い換えれば、任意のenv変数がコードインジェクションのベクトルになるとは誰も考えていませんでした。

機能が追加されたときの広範囲にわたるテストがそれを捕らえることができたかどうかに関して、私はそれがありそうにないと思います。

featureをテストするときは、機能性をテストします。機能は正常に動作します。関数を1つのbash呼び出しでエクスポートすると、別の呼び出しでも問題なくインポートされます。同じ名前の変数と関数の両方がエクスポートされる場合、または関数がエクスポートされたロケールとは異なるロケールで関数がインポートされる場合、非常に徹底的なテストで問題が発見される可能性があります。

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

これは開発者（特に1989年）がしばしば心の底に持っているものではなく、シェル開発者は彼のソフトウェアがネットワークで悪用される可能性が低いと考えるよう言い訳される可能性があります。

205
Stéphane Chazelas

NISTのNVDデータベース（ http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271 ）によると、1.14.0以降のすべてのバージョンのbash以降は脆弱です。

RedHatは 9月14日 でバグの影響を受けました。

Mr.Ramey（bashメンテナ）が2014年9月26日にリリースしたパッチは CVE-2014-7169バグ を修正します。

これらおよび以前のすべてのパッチを対応するbashソースに適用します。

Bashの追加の脆弱性

バグの履歴についてもう少し（ mikeserv 提供）

ソース： http://www.linuxmisc.com/12-unix-Shell/e3f174655d75a48b.htm

1994年に、Chet Rameyは、とにかく、エクスポートされた関数を指定した古いPOSIX 2仕様よりも古いものだと説明しました。あるいは、少なくとも、彼はbashメカニズムをそうしていると説明しました-それが当時私と同じくらい欠陥があるかどうかはわかりません。また、そのスレッドでのrcの関数エクスポートについても説明します。

19
Deer Hunter