setuid
スクリプトが、LD_LIBRARY_PATH
のようないくつかのブラックリストに記載されたものを除いて、呼び出し元からの任意の環境変数を取る場合、これは#!/bin/bash
を直接または間接的に実行するsetuid
スクリプトが特権のローカル昇格のベクトルであることを意味しませんか?
これがなぜそうであるか、そうでないのかを説明するのが良いでしょう。
たとえば、多くの(ほとんど?)unixalikeは現在、シェルスクリプトでsetuid
を尊重していません(ただし、このバグ/バックドアが導入されたときはそうでした)。しかし、バイナリはシェルスクリプトを間接的に呼び出す可能性があるため、最初に明示的に環境をクリアしない限り、これはまだ問題ではありませんか?
はい!
setuid
ビットを含み、(直接的または間接的に)bash
からexecve
、popen
またはsystem
を呼び出すバイナリは、使用できるツールですシェルショックバグをアクティブにします。
これらのコマンドがbash
(またはシェルスクリプト)を実行する前に*env
をクリアしない場合、これらのバイナリを使用して任意のコマンドを実行できます(例:bash
) root
の権限で。
popen
およびsystem
は、プログラマが*env
をクリーンアップする可能性を与えません。
推定このリスクに対する簡単な監査の最初のドラフトは次のとおりです。
find / -perm +4000 \
-exec /bin/zsh -c "ls -dluT {} ; nm -a {} | egrep '(popen|system|execve)' && strings {} | egrep '/bin/(sh|bash)'" \; 2>/dev/null
シェルのフォークの前に*env
がクリーンアップされている可能性があるため、これはproofのリスクではありません。確実にする唯一の方法は、ソースコードを読むことです。
そして、これは、頻繁に使用されるUnixの実際のバージョンでの結果です。
-rwsr-xr-x 1 root wheel 910848 Sep 29 16:31:18 2014 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
U _popen
/bin/bash
(ここで最後に使用したのは、攻撃の証拠ではなく、私自身の以前の「ドラフト監査」の証拠です。)
bash
がsetuid(またはsetgid)コンテキストで呼び出された場合、つまり有効なuidが実際のuidと異なる場合、bash
は特権を削除します(有効なuidを実際のuidに戻します) )。
その例外は、_-p
_または_-o privileged
_(SHELLOPTS
変数は無視されるため、privileged
もそこに含まれる)を使用する場合、またはsh
。
その場合でも、関数は環境からインポートされません(同じ明らかな理由により、_BASH_ENV
_、_BASH_OPTS
_、SHELLOPTS
なども同様です)。
もしそうなら、それを利用するのにShellshockの脆弱性は必要ないでしょう。 echo
関数(または_/bin/mount
_のようなパスを含むスクリプトによって呼び出されるもの)をエクスポートするだけで十分です。
一部のsetuidコマンドは、ruidをeuidに設定することを選択する場合があります。環境をサニタイズせずにbash(または他のシェル)を呼び出す場合、ゲームオーバー、Shellshockの脆弱性かどうか。
Libcの動的リンカーは、libcまたはリンカーに影響を与えるいくつかの変数(LD_PRELOAD、LOCPATH、LD_LIBRARY_PATH ...)を削除しますが、シェル(またはpython、Pythonなどの他のコマンドを呼び出した場合、残りをクリアするのはsetuidアプリケーション次第です。または環境変数で動作を制御できるその他のコマンド)、一般的な正気なアプローチは、サニタイズされたホワイトリスト以外のすべてをクリアすることです。
このようなアプリケーションの典型的な例は、Sudo
です。
デフォルトでは(_env_reset
_オプションがオンの場合)、Sudo
は環境をクリアし、いくつかを設定します(PATH
、HOME
、_Sudo_USER
_など)。 。)およびTERM
やDISPLAY
などの内容を確認した後、ホワイトリストにいくつか登録します。そのチェックの一部は、コンテンツが_()
_で始まる変数を特別に処理します。
_env_reset
_がオフ(ユーザー/管理者によって無効にされている)の場合でも、Sudo
はさまざまなシェルや他の一般的なツール(_PS4
_、_BASH_ENV
_など)に影響するいくつかの変数をブラックリストに載せます...)およびコンテンツが_()
_で始まるもの。
したがって、Shellshockは次の方法で悪用することはできません。
_DISPLAY='() {(:);}; ouch;}' Sudo trusted-bash-script
_
Ruidを設定し、_()
_で始まる変数をチェックせず、bash
を(おそらく間接的に)呼び出さないsetuidコマンドが存在する可能性がありますが、ここでもShellshockバグは必要ありませんそれらを悪用する。
これに対する可能な例外は、Apacheのsuexec
です。私の知る限り、suexec
は環境をサニタイズしますが、コンテンツではなく、名前に基づいて一部の変数のみをホワイトリストに登録します。 CVE-2014-6271がなければ、QUERYSTRING
、_HTTP_USER_AGENT
_などの変数名はコマンドの名前と一致しない可能性が高いため、これは問題にはなりません。コンテンツが"() {"
で始まる変数をブロックしますが、実際には、CVE-2014-6271に公開されていることを意味します。