10月に入り、9月までに起こったことをざっと振り返るというお題がどこかから聞こえてきたので、「 じゃあ……」という感じで振り返ってみることとします。
わずか1週間程度でBashが大幅な進化を遂げた ～Shellshock大暴れ～
まだ現在進行形の事案ではありますが、9月下旬に発覚したBashの脆弱性に起因して、10月上旬までまだ収束していないShellshock。
Bash 4.3の例で説明すると、Patchlevel 25～30までは以下のような軌跡をたどっています。
9月24日にPatchlevel 25
9月26日にPatchlevel 26
9月27日にPatchlevel 27
10月1日にPatchlevel 28
10月2日にPatchlevel 29
10月5日にPatchlevel 30
この間に発見、修正された脆弱性は、CVE-2014-6271、CVE-2014-7169、CVE-2014-7186、CVE-2014-7187、CVE-2014-6277、CVE-2014-6278の6つになります。
どの脆弱性がどのパッチで対処されたのか？ という対応については、JPCERT/CCによる注意喚起文書に詳しく書かれています．
何が悪いのか？
JVN の該当記事には、以下のように書かれています．
GNU Bash には、環境変数にシェル関数定義を設定して他のシェルプロセスに渡す機能と、環境変数で設定されたシェル関数定義を取り込む機能が存在します。 関数定義に続きシェルコマンドが記述されている形で環境変数が設定されているとき、GNU Bash は関数定義を取り込む際にそのシェルコマンドを実行してしまいます (CWE-78)。
GNU Bash に OS コマンドインジェクションの脆弱性
上記の文章が意味するところを少し説明してみます．
確認用のスクリプトを見てみる
Red Hat から提示された「脆弱性があるbashであるかどうかを確認するスクリプト」を見てみましょう。
env x = '() { :;}; echo vulnerable' bash - c "echo this is a test" このスクリプトが何をするか？ は、envコマンドのmanを見てみると良いでしょう。envコマンドの書式は以下のとおりです。
env [ OPTION ]... [-] [ NAME = VALUE ]... [ COMMAND [ ARG ]...] envコマンドは、環境変数を“ NAME=VALUE” での指定に従って設定し、その状態で“ COMMAND [ARG]” として指定されたコマンドを実行します。 上記のスクリプトの場合は、環境変数xに“ () { :;}; echo vulnerable” を設定し、その状態で“ bash -c "echo this is a test"” というコマンドを実行します。 今回、“ (){ ;;}” と指定された部分は、何もしない無名関数の定義になります。
上記のスクリプトから“ bash -c "echo this is a test"” の部分を抜いたものを実行してみると、環境変数がどのように設定されるかが良くわかります。
# env x='() { :;}; echo vulnerable'
（省略）
x =() { :;}; echo vulnerable
（省略）
この時点で、xには無名関数＋echoコマンドが記述されています。
環境変数にこのように設定された「だけ」ではまだ何の悪さもしませんが、今回その後に指定されたbashコマンドがこの環境変数類を取り込む際に、どのようにするか？ を見てみましょう。 そのためには、envコマンド経由で実行するコマンドを“ bash -c set” として、環境変数を表示させるのが手っ取り早いです。
# env x='() { :;}; echo vulnerable' bash -c set
vulnerable
BASH = /bin/ bash
（省略）
x ()
{
:
}
#
見るとわかるのですが、“ echo vulnerable” という部分が消えてます．先ほど環境変数で設定した内容が新たに起動されるbashに取り込まれる際に、xという名前の関数に展開されるわけですが、この時に“ echo vulnerable” という部分が実行され、“ vulnerable” という文字列が表示されます。
よく言われるのは、CGIとして動作するシェルスクリプトがある場合には影響を受けるという話ですが、Server-Side Includes（SSI）として動作するシェルスクリプトがある場合にも同様に影響を受けます（どちらの場合も当該シェルスクリプトがbash上で動く場合） 。
最も確実な対処方法はアップデートだが、単体でアップデートできない場合も
本脆弱性は結構根深く、早急なアップデートを推奨される類のものです。放置しておいて良い類のものではありません。さらに、OSのシェルだけでなく、アプライアンスの類にもbashが入っているケースが多々見られます。CERT/CC が公開している情報に、どのメーカの製品が脆弱性の影響を受けるか？ というリストがあります。
これを見ると、F5やFireEyeなどからリリースされているアプライアンス製品も影響を受けることがわかります。
Vulnerability Note VU#252743
メーカのドキュメントには、影響を受ける製品やファームウェアアップデートの可否、そしてアップデートできない場合の緩和策が書かれていることが多いので、対処の際には参照されることをお勧めします。
なお、OSのbashをアップデートしてもバージョン表記が変わらないこともあります。このあたりは、本連載の第1回にも述べていることですが、留意していただくとともに、早めにアップデートした方も「さらに新しいものが出ているか」と言うことをご確認いただくのが良いでしょう。
あと、当然ですが、自分が管理していない他のシステムを（実際にコマンド起動を試みるような形で）確認してまわるのはやめましょう（実際、筆者のところにもそういうスキャンが来ているのを確認してます） 。あくまで確認は「自分が管理するシステム」もしくは「正式に確認を依頼されたシステム」のみです。
今回参考にした文献
