世界中の技術者が震撼？　Bashの『Shell Shock』問題がヤバイ #ShellShock

2014-09-25 23:40

タグを編集ログイン

（2014/09/25 20:00 時点での情報です）

今朝あたりから、GNU Bash の脆弱性（CVE-2014-6271、CVE-2014-7169)が　巷で大騒ぎになっています。

概要

Bashアホ

e7ad5a04c600432dd202c28f6a923273f1c6b1c0

42c169def567557198e7b1efc21309cf3ff8dda7

3d120108ff16543da7b08d92fbdb8e4d3f92517c

環境変数が小細工されていると、bashを実行しただけでご覧の通り、環境変数の中身に記述したコマンドが実行されてしまうという非常にヤバイ脆弱性です。

例えば、CGI経由でbashスクリプトを実行できるようにしていた場合、User-Agent等に上記の小細工した文字列を設定してリクエストを投げるだけで、遠隔操作ができてしまいます。その結果、アカウント情報やその他の機密情報（/etc/passwdやSSLの秘密鍵等）を盗まれたり、WEBサイトを改ざんされたりする可能性があります。

さらに

・CGI及びPython経由でbashを呼び出していても影響を受けることがある
・cPanelのdefaultwebpage.cgiなど有名なスクリプトも影響を受ける

等の情報もありますので、地味に影響範囲が広いと思われます。

影響バージョン範囲は、JPCERTによると、

  - Bash 4.3 Patch 25 およびそれ以前
  - Bash 4.2 Patch 48 およびそれ以前
  - Bash 4.1 Patch 12 およびそれ以前
  - Bash 4.0 Patch 39 およびそれ以前
  - Bash 3.2 Patch 52 およびそれ以前
  - Bash 3.1 Patch 18 およびそれ以前
  - Bash 3.0 Patch 17 およびそれ以前

となっています。

主に影響を受けるのはLinuxですが、OSXも影響を受けるようです。
また、Windows上のcygwinやmsys（msysgit）上のbashも影響を受けます。

なお、標準シェルをzsh等に変更している方でも、ディストリビューションによっては、「/bin/sh」がbashへのリンクとなっている場合があるため、影響を受ける可能性があります。

現在提供されているパッチは不完全なため、あくまでも適用は緩和策に過ぎません。

対策

（1）各ディストリビューターから配布されているアップデートを適用する

例えば、Ubuntuの場合は「sudo apt-get update && sudo apt-get upgrade」コマンド等でアップデートを実施してください。

ただし、現在提供されているパッチは不完全なもののため、完全な回避策とはなりません。
あくまでも緩和策と考えて下さい。

OSXの場合は公式では提供されていないようですので、MacPortsなどを使用する必要があるようです。

また、今後、OSのアップデートだけでなく運用している各WEBアプリケーションのアップデートも念のため確認した方がよさそうです。

（2）リモートからbashを起動できないようにする

例えばCGI経由でbashスクリプトを呼び出せるようにしている場合は、代替シェルを使用するよう変更するか、脆弱性が解決されるまで「chmod -x hogehoge.cgi」で一時的に実行できないようにしましょう。

（3）WAFを使用する

運用しているWEBアプリケーションについて、どうしても根本対策が行えない場合は、WAFを使用して攻撃をフィルタすることも考えられます。ただし、WAFはチューニングが難しいと思われるので、難しい所ですね。

詳細

詳細を取り上げたいところですが、既に情報は既に様々なページで取り上げられているので、それをご覧下さい。

Blog: bashの脆弱性がヤバすぎる件 – x86-64.jp - くりす研
 https://x86-64.jp/blog/CVE-2014-6271

Bash 脆弱性 - ShellShock- (1) CVE-2014-6271 / CVE-2014-7169 絶賛対応中です - CLARA ONLINE techblog
http://techblog.clara.jp/2014/09/bash-vulnerability-vol1/

BASHの脆弱性でCGIスクリプトにアレさせてみました - ブログ - ワルブリックス株式会社
 http://www.walbrix.com/jp/blog/2014-09-bash-code-injection.html

その他「#ShellShock」のハッシュタグで検索すると新しい情報が掴めるかも知れません。

所感

今年はオープンソース界隈で重大な脆弱性が次々と明らかになりますね……。
沢山の目があっても、こういう脆弱性は見落とされてしまうものなのでしょう。（あるいはわざと仕込まれていたという陰謀論もありますが）

少なくとも『Linuxだから安全』というのは、神話の世界の話ですね。

ちなみに、今回の問題は、環境変数の内容が関数ぽかったら関数として解釈してしまう上に、その過程で後続のコマンドまで実行してしまうというところが問題です。入力を無条件で信用してはいけないという原則を見事に無視した、bashの仕様がアホすぎるという印象ですね。

とはいえ、さすがに環境変数に変な値を仕込まれただけで、コマンドを実行してしまうという斜め上の発想のプログラムが存在するとは思いも寄らなかったのでしょう。この手の脆弱性への対策はこれまであまり議論されてこなかったように思います。今回のケースでは、リモート攻撃にもローカル攻撃にも使えますからね……。

プログラムを開発するときは、環境変数からの入力も当然ながら信用してはいけないというのは大原則なのですが、そもそもシェルスクリプトでは変数や引数の内容をエスケープするための良い方法があまりないので、元々、外部公開するのには向いていないように思います。まあ、固定処理をキックするためだけのwebhook用cgiには便利なんですけどね…ｗ　少なくともシェルスクリプトはCGIに使用せず、CGIではPerlやPHP経由であってもシェルを呼び出すのは避けた方が良いのだと思います。

あと、「うちはLinuxを使ってないから大丈夫」だとか、「社内向けのサーバーで外部には公開していないから大丈夫」かというとそうでもありません。Linuxを使っていないつもりでもNASのOSがLinuxだったということもありますし、そもそも情報流出は内部犯の方が多いという説もあります。くれぐれもご注意を。

以前大騒ぎになったHeartbleed問題もそれなりに大きな問題だったのですが、SSL通信内容や秘密鍵の情報が盗めるだけでした。（いや、「だけでした」では片付けられませんが）

しかし、今回の問題は、情報を盗むだけで無く、任意のコマンドが実行できてしまうという点でそれの比ではなさそうです。ワームの登場も待ったなしでしょうし、被害者どころか加害者となってしまう可能性も高いといえそうです。そして、アクセスログにUser-Agent以外の情報は残していないことも多いでしょうから、攻撃を受けていても気付かない可能性がある、というのがもっと怖い所ですね。

ちなみに、脆弱性は公表された日から話題になった日が危険ですから、迅速な対応が必要です。
実はOPAP-JPのWEBサーバーにもさっそく攻撃のログが残っています。

xxx.xxx.xxx.72 - - [25/Sep/2014:10:31:44 +0900] "GET / HTTP/1.0" 302 436 "() { :; }; ping -c 11 xxx.xxx.xxx.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
yyy.yyy.yyy.125 - - [25/Sep/2014:15:08:26 +0900] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 302 436 "-" "() { :;}; /bin/ping -c 1 zzz.zzz.zzz.138"

本当早速ですよ。
スゴイですね。

まあ、悪意のあるものとないものがあるとは思われますが、特に2番目のログは怪しい気がしますねｗ
ちなみに、302になっているのは攻撃が成立しているのではなく、未定義のHostでアクセスされた場合は、「こうしす！第1話」に無条件リダイレクトするようにしているからです。

やったね！

というわけで、今回の内容とはまったく関係ない作品ですが、まだ「こうしす！第1話」をご覧頂いていない方はぜひご覧下さい！　

（まさかの宣伝オチ）

! 違反報告