_ IW2014 DNS DAYのプログラムが発表されてました。今年も喋ります。お題は IP53B。よろしく。
_ 内容は IP53B に関連するんだけど、持ち時間があまり長くないのと、あくまで "DNS" DAY ということでテーマがそぐわないかもということで、当日に喋らないかもしれないネタを今のうちに投下してみる(余裕があれば喋りたい)。
_ SSDPというプロトコルがあるですよ。UPnP で使われるもの。1900/udp。はい、UDP です。amp 攻撃の踏み台に利用可能。 増幅率はおよそ30倍ぐらい。踏み台になりうるオープンな SSDP サーバは、 全世界で1700万台、国内に65万台も存在している模様。 オープンリゾルバよりも多い。
_ さらに悪いことに、オープンソースの複数の SSDP 実装には、外部から任意コードを注入できる 脆弱性の存在しているものがある。最新版ではすでに修正されてるけど、UPnP で使われるということからもわかるとおり、これを使っているのは PC 上のアプリケーションではなくブロードバンドルータなどの周辺デバイスであって、OS ベンダーのサポートはまったく期待できず、機器ベンダーのファームウェア更新を頼るしかない。販売終了した製品のファームウェア更新がどれだけ続くのかは謎。
_ そして、8月末ごろから、実際にこれを狙った amp 攻撃が 実際に観測されはじめている。
_ 対策としては、(1)対策ファームウェアへの更新、(2)外部から 1900/udp にアクセスできないようにする、(3)ISP での IP1900B などが有効。コード実行の脆弱性の対策という意味では(1)だけでもいいけど、amp の踏み台になるのを防止するという意味では、また UPnP の本来の用途から考えても (2) が実施されることが望ましい(ファームウェア更新で穴だけでなくポートもふさいでもらえるのがいちばんありがたい)。そして、(2) と同等のことをもっと上流でおこなう (3) が視野に入ってくる。
_ ちうことで、ISP のみなさまは IP53B と関連して、IP1900B も検討してくださいませ。
_ なお、IP1900B が実施されると、その下流にいる UDP クライアントがたまたまソースポートとして 1900 番を使ってしまった場合に、サーバからの応答パケットが IP1900B にひっかかって受けとれないという問題が起きる。IP53B は well known port なので、ソースポートを53番に固定している残念なキャッシュ DNS ぐらいしか影響はないんだけど、1900 は WinXP を含む古い OS ではエフェメラルポートとして利用される範囲に含まれちゃってるので、たとえば 8.8.8.8 で名前解決するように設定するとごく稀に IP1900B にひっかかって名前解決に失敗する可能性がある(Vista 以降なら大丈夫)。
_ ぽかーん。環境変数をごにょごにょするとそいつがコードとして実行されるって。これまで見てきた中でも最高にクソな脆弱性だな。どうやればこんな穴を仕込めるんだ。
_ 説明されてるのは、
ってな例で、$x に仕込まれてる echo が実行されちゃう。手元でも確認した。これは明示的に bash を直接起動してるけど、問題は、明示的に bash を起動しなくても実行されることがあるってことだよ。影響範囲デカすぎ。env x='() { :;}; echo vulnerable' bash -c "echo this is a test"_ あるプロセスの中から別のプロセスを起動する場合、/bin/sh が暗に起動されちゃうんだよ。system(3) とか popen(3) とか、引数のコマンドを直接実行するのではなく、/bin/sh の引数として実行してるだけなんで。つまり、
のような例でもこの穴を踏む。perl の `...` は /bin/sh を呼ぶので。env x='() { :;}; echo vulnerable' perl -e 'print `echo "hoge"`;'_ このような環境変数を外部から仕込めないようになっているならそれほど影響を受けないんだけど、簡単に仕込めちゃうものがあるんだよなぁ。
X-Hoge: というヘッダに細工した文字列をつっこんで CGI にアクセスすると、サーバ側ではその値が $HTTP_X_HOGE という環境変数に入れられ、CGI の中から別のコマンドを起動すると /bin/sh が呼ばれる。つまり、リモートからコード注入可能。もう最悪だよ。curl -H 'X-Hoge: () { :;}; echo vulnerable' http://www.example.com/hoge.cgi_ bash を使ってても、/bin/sh が bash でないならば、このような注入はできないので影響はだいぶ軽減される。/bin/sh が選択式になってる debian は dash を /bin/sh として使うようにしておいた方がよさげ。RedHat 系は今すぐ修正を。MacOSX は、…いつアップデートされるのかなぁ？
_ テントかついで木曾駒に行ってきた。土曜日。千畳敷→頂上山荘テン場→木曾駒→テン場。日曜日。テン場→濃が池→宝剣岳→千畳敷。天気もよく、紅葉も見頃でたいへんすばらしい2日間だった。
_ が、そんなことより。
_ 御嶽山が噴火したというニュースを知らずに登りはじめ、視界の開けた木曾駒山頂に到達してはじめて御嶽山から噴煙が上がってるのが見えて仰天した。しかし噴火の前兆があるというニュースも聞いてないし、ほんとに噴火なのかどうか半信半疑。雲が多くて一面の雲海から山頂付近だけちょっと頭を出してる感じだったので、見ようによってはおかしな形の雲に見えなくもない。御嶽山噴火のニュースを家族からの電話で聞いたという話を他の登山者の方から聞いて、やっと噴火確定に。
_ そして今朝。雲ひとつない快晴で、噴煙も、白い火山灰で覆われた山頂付近もはっきり見える。もう見間違えようもなく噴火してる。まさかこんな景色が見られるとは。山中で一泊してニュースに接してないので詳しい状況はわからないので、怪我した人が少なければいいなぁ、ぐらいにしか思ってなかった。下山後に温泉で汗を流して、休憩所にあった新聞で初めて予想を遥かに越える被害があったことを知ってまた仰天。
_ …のだが。PC 故障。起動後数秒〜1分以内に画面が反応なくなる。リモートからログインはできるが、10分程度で勝手に再起動するので実質的に使えない。もう1台あるけど、こちらは通常の操作には支障はないものの、CF カードスロットが故障しててカメラで撮った写真を読み出せず。USB でつなげればいいはずだけどケーブル行方不明。ということで今は写真なし。
_ OSX は /bin/sh が bash だけど、ふつーに使ってるかぎりは問題ないよという 公式声明。うん、自分の認識もこれと同じ。 バグありなのは事実なので可能ならば更新した方がいいにきまってるけれど、公式のアップデートを待たずに入れ替えるべきかというと、そこまで急ぐ必要はない。だからといって公式対応が遅くなっていいという話ではないんでとっととアップデート出してくれ。
_ もちろん、外部からアクセスされる httpd が動いていて CGI も存在してれば危ないけど、それは OSX のふつーの使い方ではない(断言)。こういう使い方をしてるならヤバいので止めるか自力更新するかが必要。
_ DHCP のクライアントは大きくわけて2つの動作をする。ひとつは DHCP サーバから自分に割り当てられる IP アドレスその他の情報を取得すること。もうひとつは、取得した情報を自身のホストに設定すること。多くの DHCP クライアント実装は、後者がシェルスクリプトで実装されていて、DHCP サーバから取得した値を環境変数に設定して呼び出す形になっている。こういった情報をホストに設定する手順は OS やディストリビューションによって大きく異なっているので、このへんを柔軟に書き換えやすいようにしてるわけ。今回の bash バグで悪意ある DHCP サーバに接続すると危険というのは、このシェルスクリプト実行時に注入されるから。
_ ただ、OSX の DHCP クライアントはシェルスクリプトを呼ばない実装になっている。よって、ここから攻撃されるおそれはない。つーことで、OSX をふつーに使っていれば、攻撃できる場所はない。
_ ヤバいのは、ノート PC に Linux を入れて持ち歩いてるような場合。あやしい無線 LAN に接続したとたんに DHCP 経由で乗っとられる可能性あり。CGI 経由のコマンド注入と違って、こいつは root を奪われるのでかなり危険。また、debian の /sbin/dhclient-script は #!/bin/bash なので、/bin/sh が bash じゃないからと安心してはいけない。
_ bash の脆弱性を踏んで qmail がやられるパターン。すでに .qmail から注入する例は挙げられてるんだけど、まったく別方向から注入できるんじゃないかと思って試してみた。
_ えーと、結果としてはセーフでした。tcpserver が接続元情報として設定する環境変数は qmail-scannerのような qmail-queue をフックするタイプのコンテンツフィルタにそのまま渡るので、この手のコンテンツフィルタが /bin/sh を経由して外部コマンドを起動してたら脆弱性を踏むんじゃないかと思ったんだけど、実際試してみたところ TCPREMOTEHOST は記号や空白文字が8進数でエンコードされて、TCPREMOTEINFO は空白文字が削除されるので、いずれも攻撃に必須な "() {" という文字列が入らない。ドキュメントには これらの環境変数は arbitrary characters を含むから注意しろ、と 書いてあるのできっと注入できるに違いないと期待してテストしてみたのに、任意の文字入らないじゃないか。ちゃんと書き換えてくれやがってつまんない。
_ つーか、TCPREMOTEHOST/TCPREMOTEINFO にセットする文字列には危ない文字を含めないようにする配慮があるなら、.qmail からプログラムに渡す SENDER とかの環境変数も危ない文字を含めないようにしようよ。というか、MAIL FROM: でこんなあからさまにおかしなアドレスは受け取らずに拒否してくれよ。
_ なお、postfix も qmail 同様に .forward から起動するプログラムに外部からの値を各種環境変数にセットするが、こちらは qmail と異なり、記号や空白文字は "_" に置換されるので脆弱性の影響は受けない。sendmail はそもそも外部からの値を環境変数にセットしない。
_ きのうの件。写真吸いだしたのでいつもより多めに晒してみる。
_ 噴火から3時間後、27日15時ごろの御嶽山。木曾駒山頂から。雲が多くこちらの方向は視界がなかったんだけど、風が吹いて雲が流れたと思ったらこの景色。そりゃびっくりするでしょ。
28日の日の出直後。同じく木曾駒山頂から。手前は麦草岳。
将棊頭山方面へ向かう道中から振り返って。紅葉は素晴しいがその後方が不穏。
宝剣岳山頂から。右が木曾駒。
宝剣岳の鎖場を抜けてひと息ついた地点から。山頂付近に白く火山灰が積もってるのがよくわかる。最初の写真を見るとわかるが、きのうとは風向きが違っていたようで、きのうの時点の風下方向がより白い。
以下、御嶽山とは関係ないお気楽な紅葉写真。濃ヶ池から。
宝剣岳山頂から千畳敷を見下ろす。
宝剣岳の鎖場。全体のうちではそれほど大した場所ではない(マジでヤバいところはカメラを構えてる余裕はない)。足を踏みはずすと数百メートル下の千畳敷まで落ちる。
おなじみ紅葉の千畳敷カール。
