2014-09-25

Bash の脆弱性について

CVE-2014-6271 の件について、何かわかってない記事が散見されるので簡単にまとめ。

問題点

環境変数が特殊な文字列の場合、Bash はそれを関数定義とみなす(この仕様がそもそもどうなのよ、と思う人は/bin/shをbashにするのはもうやめましょう)。そのロジックに誤りがあり、関数定義でない部分も読み込み、その部分が実行されてしまう。

影響範囲

/bin/sh が bash でないシステムの場合

明示的に bash スクリプトとして起動されたスクリプトだけが影響を受ける。ただし SSH サーバーの場合、ユーザープログラムを実行する場合にユーザーのシェルを使用するので、そこで影響を受けることがある。

/bin/sh が bash であるシステムの場合

system(3) や popen(3) が内部で /bin/sh を利用しているので、影響は広範に渡る。

CGI


特に話題になってるのが CGI である。CGIは仕様 (RFC3875) により、外部から受け取った情報を環境変数に入れた上で (section 4.1.18 参照) 外部コマンドを実行することになっている。ウェブサーバーの実装によるが、このとき system(3) (またはそれに類する) を使って外部コマンドを実行していれば今回の脆弱性の影響を受ける(が、普通は system(3) は使わないし、少なくともapacheはそんなことしない)。

また、環境変数は明示的に制限しない限り子供のプロセスにも引き継がれるので、ウェブサーバーが system(3) を使っていなくても、そこから起動されたプログラムがさらに外部コマンドを system(3) 相当で起動した場合、同じように脆弱性の影響を受ける。

SSH

openssh はサーバー側の AcceptEnv の設定(とクライアント側の SendEnv)によっては手元の環境変数をリモートに送ることができる。環境変数が評価されるのは認証後なので、通常はあまり大きな問題ではないが、サーバー側で ForceCommand で特定のコマンドしか実行しないようにしていた場合、それをバイパスすることができる。なお、ForceCommand はそのユーザーのシェルで実行されるので、zsh とかにしていると影響を受けない。

<追記>
bugレポートちゃんと読んでなかった。もしかしたら AcceptEnv に関係なく TERM は送られるかも。それと、ForceCommand の場合、クライアント側の引数が SSH_ORIGINAL_COMMAND 環境変数にセットされるので、ssh remote_host "() { :;}; ..." とかするだけでいけるっぽい。
</追記>

なおほとんどの人には関係ないとは思うが、クライアント側で ProxyCommand でモニョモニョしている場合、ProxyCommand は実行ユーザーのシェルで解釈される (/bin/shではない) ので、もし ProxyCommand にもクライアントの環境変数が渡る場合(まだチェックしてないので、誰かチェックしてよー)は、リモートを攻撃しようとしてたら何故か自分を攻撃してたということもなきにしもあらずなので、そんな人は注意が必要である。

<おまけ>
ForceCommand とか ProxyCommand が /bin/sh を使わないのは、多分、ユーザーのシェルを制限付きシェル (rsh, rbash) にしてセキュリティを強化たい場合用のはず。
</おまけ>

dhclient

DHCPクライアントの実装の一つである dhclient は、システム管理者によって簡単にカスタマイズできるように、受け取った情報を環境変数に入れた上で各種スクリプトを起動する仕組みになっている。偽の、というか勝手に DHCP サーバーを立てるのは簡単なので、偽DHCPサーバーから偽装された応答を返すことで、DHCPクライアントが動いているホストを乗っ取ることができる。DHCPクライアントは root 権限で動くので深刻な問題になりうる。

CUPS
よく知らん。バグレポートに影響受けるよって書いてあった。

prometheusのrate()関数の罠

 久しぶりのAdventカレンダー挑戦、うまくいく気がしません。 閑話休題。実のところ、rate()関数というよりは、サーバー側のmetric初期化問題です。 さて、何らかのサーバーAがあったとして、それが更に他のサーバーBにRPCを送っているとします。サーバーBの方でホワイトボ...