「シェルショック」関連の質問のヒープに追加するリスク...
Shellshockパッチは、環境変数の関数定義の後に任意のコードが実行されるのを防ぎます。たとえば、パッチを適用したバージョンのBashがこのホールを悪用しようとすると、次のようになります。
$ env foo='() { :;}; echo derp' bash -c 'echo herp'
bash: foo: ignoring function definition attempt
bash: error importing function definition for 'foo'
herp
これはまだ設計上許可されています:
$ env foo='() { echo derp; }' bash -c foo
derp
ただし、環境を介して関数を定義できる場合は、環境を変更する機能を持つすべてのユーザーがコマンドを任意のコードに置き換えることができます(ターゲットスクリプトが絶対パスでコマンドを指定しない場合):
$ env ls='() { echo derp; }' bash -c ls
derp
Shellshockパッチはany環境変数を使用してコードを実行できるHTTP User-Agentヘッダー攻撃などを防ぎますが、既存のコマンドの再定義を防ぐことはできません。
悪意のある任意の実行可能ファイルを含むディレクトリを指すようにPATHを変更することにより、機能を継承せずに同様の攻撃がすでに可能ですが、このシナリオではファイルシステムへのアクセスが必要です。これはしません。
では、環境からコマンドを再定義できることは脆弱性と見なされますか?悪意のある目的で悪用される可能性のある一般的な状況はありますか? (例えば、Git/Mercurial over SSH、Gitolite ...)
理論的にはそうです。しかし、あなたはまた、問題を抱えています
LD_PRELOAD
LD_LIBARAY
BASH_ENV
Shellshockの最大の問題は、環境変数の名前が重要ではないことです。bash
は、たとえば、 HTTP_COOKIES
(ところで、誰がそうするのですか?)
通常、攻撃者は変数名の一部しか選択できず、そのような名前の関数/プログラムが呼び出されることはほとんどありません(不可能ではありません)。
例えば。 SSH経由でgitを制限して、git
のみを呼び出せるようにする場合、攻撃者は環境変数git
を定義する必要がありますが、これは不可能です。
pdate:他にもローカル権限の昇格が考えられます:
フルパスで呼び出された場合でも、コマンドを非表示にすることができます
env /bin/date='() { echo fail; }' bash -c /bin/date
これはsystem
(およびその他の)呼び出しを混乱させる可能性があります。これは、その関数の1つをルートとして使用するSUID実行可能ファイルの問題です。