シェルショックの脆弱性について、私が理解できないことが 2 つあります。
検証されていない接続に環境変数の挿入が許可されているのはなぜですか? それは何の役に立つのですか?
変数を注入する機能を提供する実際のサービスは何ですか?
何か案は?
シェルショックの脆弱性について、私が理解できないことが 2 つあります。
検証されていない接続に環境変数の挿入が許可されているのはなぜですか? それは何の役に立つのですか?
変数を注入する機能を提供する実際のサービスは何ですか?
何か案は?
環境変数は、子プロセスと通信するための非常に一般的な方法です。「子プロセスに引数を渡すことができるのはなぜですか?」と尋ねることもできます。もちろん、環境変数にはもう少し注意が必要です。これは、一部の環境変数 (PATH
たとえば、) が一部のシステム コールのセマンティクスに影響を与えるためです。したがって、通常の慣例では、設定できる環境変数を、信頼できない入力から既知の名前のセットに制限します。
たとえば、CGI プロトコル (環境変数を使用して HTTP 要求に関する情報を通信する) は、CGI 標準として大まかに記述されている環境変数名のセットと、名前が で始まる任意の環境変数に自身を制限します。文字HTTP_
。
CGI はおそらくユーザー入力環境変数の最大の在庫を持っていますが、この手法はかなり一般的です。確立された例の 1 つは、 を使用しTERM
てリモート端末の端末タイプを定義することですが、他にもたくさんあります。
コマンドライン パラメーターなどの環境変数は注意して扱う必要があり、場合によってはバリアが必要になります。この/bin/env
ユーティリティは、実行可能ファイルに指定された環境をクリーンアップするメカニズムを提供します。これは、環境が信頼できない場合に役立ち、実行可能ファイルが昇格された特権で実行されている場合に不可欠です。
特定のケース ( など) を除いPATH
て、環境変数がクリーンであることにアプリケーションが依存するべきではありません。最初に有効性を確認せずに環境変数の値に基づいて何かを行うことは、ユーザー提供データの他の検証されていない使用法と同じくらいバグです。(qv SQL インジェクション攻撃。) そして、それがここにあるものです: 単純明快なバグです。これらのことが起こります。私たちは完璧ではありません。(このバグが 20 年以上もの間、明らかに誰も気付かないまま存在していたという事実は、少なくとも興味深いものです。)
1) 脆弱性は実装上のバグです。信頼できないソースからの環境変数への命令の挿入は、意図的に許可されていませんでした。これがバグである理由です。
2)脆弱性が悪用される方法の良い例については、http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html#.VCNyvfmSx8Eを参照してください。