shellshock.md

Shellshock

多くのLinuxシステムでデフォルトシェルとなっているbashに、 環境変数を通して任意のコマンドが実行できる脆弱性が見つかった。 いわゆるコマンドインジェクションというものである。

概要

環境変数の設定で関数定義に続く形でコマンドが書かれた場合、 bashがそのコマンドが実行してしまうバグがあった。 例えば次のようなコマンドで

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

脆弱性が存在する場合、 echo vulnerable が実行されて

valnerable
this is a test

と出力される。

単純にこの動作だけでは脆弱性と言い切れるかどうか微妙だが、 CGIがリクエストの情報を環境変数として持つ、 /bin/shが実はbashのエイリアスなLinuxが多いという特徴により、 問題はより大きくなり完全に脆弱性となった。 例えばHTTP_USER_AGENTヘッダに() { :;}; cat /etc/passwdという文字列を設定してリクエストすると、サーバ上でcat /etc/passwdが動いてしまう。 直接bashでCGIを書いてなくても、各プログラミング言語のsystem関数あたりを使ってしまうとアウトになる場合がある。 ただし/bin/shの実体がbashではない場合問題にはならない。 具体的にはDebian系はdashという別のプログラムなので問題がない確率が高い。 サーバOSとしてなぜか人気があるredhat系は危ない。

これはheartbleedより遥かに強烈で、CGIユーザの実行権限がある範囲では何でもできてしまう。 より直接性の高い攻撃が可能だ。

例えば以下のような方法で確実性を持って証明書や秘密鍵を盗むことが可能だ。

1. () { :;}; cat /etc/nginx/nginx.conf でnginxの設定ファイルを読む
2. 設定ファイルに書かれたssl証明書のありかを () { :;}; cat /path/to/cert で読む

heartbleedは運が必要だったがこの攻撃方法に運は必要ない。 Linuxの設定ファイルがだいたい同じルールに従って置かれていることも攻撃を簡単にする。

任意のコマンドが実行可能なので、サーバにデプロイされたコードを読むことも書き変えることもできる。 不正なソフトウェアを動かしバックドアを仕掛けることもできるし、別の攻撃の踏み台にすることも可能だ。 ユーザ権限でCGIを動かしていて、そのユーザがsudoersでNOPASSWDなんかに設定されていた場合はもう手の施しようがない。 完全に死だ。

そして脅威はサーバだけに留まらない。 ルータなどの多くの組み込み機器や、テレビやゲーム機などの家電製品も、 多くは内部でLinuxが動いている。 これらの機器を使う多くの人は、問題があったことも、Linuxが動いていることも知らないし、対策が示されたとしてもそれを実行するスキルがない。

対応

問題発覚後すぐに修正パッチがリリースされたのでそれを適用する。 修正漏れなどが見つかり何度かに分けてリリースされたが、今はもうすべて修正されているはずだ。 事前に回避する方法はなく、運が悪かったと思うほか無い。 もしくはredhatを使った過去の自分を恨んでdebianサイコーと叫ぼう。

実際に攻撃を受けたかどうかはhttpログなどを見るとよい。 外部からの攻撃はほとんどがhttp経由だろうと予想される。 ログが消されていないと仮定すると、受けた攻撃はすべてその中に書かれている。 他のプロトコルも開放しているならそのログも見たほうがいいかもしれない。

Webサーバを動かしているユーザ権限で何ができるかチェックしたほうが良い。 例えばデプロイされているファイルのwrite権はあるのかどうか。 ログファイルのwrite権はあるのかどうか。 ファイルのwrite権があるなら、コードをデプロイし直さないといけない。 ログファイルのwrite権があるなら、攻撃の有無の確認にログファイルが使えないかもしれない。 現状が確定できない何かがあるなら、サーバを捨てて新しい環境を作りなおしたほうがいい。

一般ユーザが取れる対応は非常に難しい。 まず何が影響を受けるのかすらわからない。 とりあえず一番影響を受けそうなのはルータだが、 一般家庭にあるようなルータは、bashのようなリッチなものではなく、 小さなシェルしか持っていないらしく、その点では致命的な事態にはならなくて良かった。 とりあえずメーカサイトをチェックするなりファームウェアの更新をチェックし続けるしか無い。 何もアナウンスがない場合、安全側に倒してそのルータは捨てるべきかもしれない。 メーカーサイトはとりあえず問題ないなら問題ないとアナウンスしてくれ・・・

その他にもカスタムROMなどを入れたandroidもbashを含む可能性があって危ないらしい。 カスタムROMとかrootedとか基本的にセキュリティを全部捨て去ることなので絶対にやるべきではない。 さっさと滅んで欲しい。 rootedしたがる人間もカスタムROM製作者もNexus以外の端末も。

総括

Shellshockはあれだけ騒がれたHeartbleedより更に危険な、最大レベルの脆弱性と判定された。 多くのレンタルサーバでデフォルトとなっているCentOSに影響があり、 この脆弱性の意味をわかっていない素人Web管理者の多くは未対応だと思われる。

専任のサーバエンジニアのいる規模の大きなWebサービスはすぐに対応したと思われるが、 一般的なWebページといわれようなサイトの多くはいまだに危険な状態で放置されているだろう。 ショボい独立系ECサイトは一番狙い目危ないと思われる。

今回の問題は、サーバ管理者もユーザも、事前に避けることは不可能だった。 このような問題はいかに素早く対応を完了するかが問われる。 昔から言われていることだとは思うが、 ユーザは昨今特に信頼できるサービスを選別する能力が求められている。 ユーザが決められる唯一の事は、どこに個人情報を預けるかという事だけだからだ。 そのためにもセキュリティ知識は必須なのではないだろうか。