第３３４号コラム：上原 哲太郎 理事 （立命館大学 情報理工学部 情報システム学科 教授）
題：「今年はソフトウェア脆弱性の当たり年？」
今年(2014年)は本当に驚くほど深刻かつ影響範囲の大きいソフトウェア脆弱性が次々報告されており、後年から「当たり年」として記憶されるような年になりそうです。まずはそれを振り返ってみましょう。
まず4月、広範に使われているSSL/TLSライブラリであるOpenSSLに深刻な脆弱性が見つかりました。これはSSLの仕様にあるHeartbeatという機能の実装の不具合に起因していまして、攻撃者はこの不具合を突いてOpenSSLが用いられている各種サーバのプロセス内のメモリの一部を読み取ることができます。このメモリ内には、直前の利用者のユーザ名やパスワード、HTTPS通信時のCookie、そしてサーバ側の秘密鍵が入っている可能性があります。この脆弱性はその攻撃の容易さから非常に重要とされ、「HeartBleed」と名付けられて、大規模な対応キャンペーンが行われました。対応は単にOpenSSLを最新に更新するだけでよいのですが、やはりサーバ系にそれを適用するには時間が必要です。その対応が広がる前に攻撃が相当数行われ、カナダ歳入庁はじめ、いくつかの重要なサイトが深刻な被害を受けました。個人的には、攻撃が成功するかは多少運次第のところがあるので被害が広がるかどうかと思っていたのですが、実際には思ったより被害が大きく、攻撃側の技術の向上を改めて感じた事案です。なお6月には、同じくOpenSSLにCCS Injectionと呼ばれる脆弱性も株式会社レピダムによって報告されました。
The Heartbleed Bug
http://heartbleed.com
OpenSSLの脆弱性に関する注意喚起
http://www.jpcert.or.jp/at/2014/at140013.html
CCS Injection脆弱性(CVE-2014-0224)発見の経緯についての紹介
http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection/index.html
Heartbleed騒ぎと前後して、4月に中京大学の鈴木常彦先生によってDNSの仕様上の欠陥が公表され、かつて問題視されたDNSキャッシュサーバに対する毒入れ攻撃がもっと深刻な形で可能であることが示されました。条件が整えば、rootゾーンへの毒入れを通じ、キャッシュサーバの内容を自由に出来てしまう脆弱性です。これにより、毒入れされたキャッシュサーバを参照している端末(や組織）が、偽のWebサイトやメールサーバ等に誘導されるという被害が発生し得ます。当面の対応としては、各組織においてキャッシュサーバを外部からアクセス可能にしないことやポートランダム化を徹底することで毒入れの可能性を相当減らすことが出来ます。また、自ドメインが他組織で毒入れされたときに被害が広がらないようにNSの構成を見直す必要もあるでしょう。毒入れに対して効果があるDNSSECは現状十分には普及していない上、普及したとしても利用者からDNSSECが有効に働いているかどうか判断しにくい(HTTPSなどと違って、利用者にどのようにその効果を見せるか定まっていない)ことや、DNSSEC自身にも多々の問題があることなどもあって、現時点では根本的な対策への道筋が見通せていません。特に、今回公表された移転インジェクションと呼ばれる攻撃に対処するには、DNSの仕様から見直す必要があります。幸い、現時点ではこの脆弱性を用いて実利がある攻撃を行うことに誰も成功していないようで、現時点では大きな実被害には至っていませんが、それでもこの脆弱性は潜在的なリスクとして当分残り続けると思います。
キャッシュポイズニングの開いたパンドラの箱 -1-
http://www.e-ontap.com/dns/endofdns.html
キャッシュポイズニングの開いたパンドラの箱 -2-
http://www.e-ontap.com/dns/endofdns2.html
4月にはさらに、Javaアプリケーションフレームワークの一つApache Strutsのバージョン2 (Struts2)に見つかった脆弱性が、既にサポートが打ち切られたバージョン1(Struts1)にも残っていることが話題になりました。我が国では大手SIerがStrutsを好んで使っていたこともあって、Struts1を用いて構築されたWebサイトが大量に稼働中であり、既に攻撃も活発になっていたことから大騒ぎになりました。この脆弱性を用いると遠隔からClassLoaderが操作可能になり、当該Webサイトへの不正アクセスや情報詐取を始めとする様々な操作が可能になります。幸いStruts2向けに開発された緩和策がStruts1にも有効であることが分かったために比較的早期に対応されましたが、オープンソース製品を使ったSIに大きな課題を残した事件だったと思います。
Apache Struts において ClassLoader が操作可能な脆弱性
http://jvndb.jvn.jp/ja/contents/2014/JVNDB-2014-000045.html
Struts: ClassLoader の操作を許してしまう脆弱性
(CVE-2014-0094, CVE-2014-0112, CVE-2014-0113)について
http://www.nca.gr.jp/2014/struts_s20/
9月には、Linuxを中心に広く使われる高機能シェルであるbashに、極めて致命的なOSコマンドインジェクション脆弱性が見つかり、「Shellshock」と呼ばれるようになりました。bashには、複数のシェルスクリプト間でスクリプト内関数を受け渡しする機能があるのですが、その機能は環境変数が特定の文字列で始まったときにその環境変数を使って関数本体を受け渡すことで実現されています。この機能の実装が安易であったために、環境変数を使って任意のシェルスクリプトが実行可能になってしまう脆弱性がありました。なので、攻撃者が攻撃先サーバのあるプロセスの環境変数を任意に設定出来る場合、そのプロセスからbashが起動するタイミングで任意のシェルスクリプトが実行出来てしまいます。かつてはbashはそのような外部とやりとりする場面では使われることはなかったのですが、RedHat LinuxやCentOS、あるいはMacOS Xなどが利用者用のシェルだけではなくシステムで使用するシェルスクリプト実行用のインタプリタ(いわゆる/bin/sh)をbashに置き換えてしまっていた事から、とても大きな脅威になっていたことが今まで見過ごされていたのでした。環境変数に外部から操作可能な値を代入した状態で/bin/shを起動するプログラムにはCGI起動時のHTTPサーバプログラムや一部のDHCP実装が知られているほか、多くのクライアント系プログラムがREMOTE_HOSTといった環境変数に接続先FQDN名を格納することからDNSの逆引きを介した攻撃も可能であることが指摘されるなど、極めて広く深刻な影響のある脆弱性です。対策としてはbashを最新のものに更新することや、/bin/shをbashから別のものに入れ替えることが推奨されています。
GNU bash の脆弱性に関する注意喚起
http://www.jpcert.or.jp/at/2014/at140037.html
更新：bash の脆弱性対策について(CVE-2014-6271 等)
http://www.ipa.go.jp/security/ciadr/vul/20140926-bash.html
GNU Bash に OS コマンドインジェクションの脆弱性
http://jvn.jp/vu/JVNVU97219505/index.html
さらに10月になって、SSL3.0のうちブロック暗号をCBCモードで利用した暗号通信に、仕様上の脆弱性が見つかりました。2年ほど前に話題になったBEAST攻撃に似ていますが、SSL3.0におけるCBCモード時のパディング処理の特徴を生かしてより攻撃の条件を緩和したものとなっており、POODLE攻撃と呼ばれています。攻撃法はBEASTと似ており、攻撃者は中間者攻撃を行うことと、被害者に何度も任意のURLに対するHTTPS通信を繰り返させることができれば、「1バイトずつ総当たりで暗号文を解読しつつ、通信文を1バイトずつずらしていく」手法により暗号文の中の文字列(具体的にはCookie）を解読できるというものです。攻撃の条件が限られているので、HTTPSにおけるCookie解読くらいにしか事実上は使えないだろうとみられています。対応策はTLS1.0以上で通信させることか、ストリーム暗号を使うようにサーバやクライアントを設定することですが、SSLにおけるストリーム暗号であるRC4にはもっと深刻な脆弱性が報告されているため個人的には前者をお勧めします。TLS 1.0以上に対応しないWebブラウザはパソコンではInternet Explorer 6くらいしか残っていないので、ブラウザ側の対応は比較的楽だと思われますが、サーバ側では未だにSSL3.0を要求するサイトも少なくないため対応には時間がかかるでしょう。
SSLv3 プロトコルに暗号化データを解読される脆弱性(POODLE 攻撃)
http://jvn.jp/vu/JVNVU98283300/
SSLv3仕様そのものに対する POODLE attack について
https://www.cellos-consortium.org/jp/index.php?PoodleAttack_20141015_J
このようにざっと思い当たるだけでもこれほどの大きな脆弱性が次々と報告された年となりましたが、これらにかかる状況を見ながら、個人的には思うところが多かったので少し五月雨式に書いてみます。
1 オープンソースソフトウェアの脆弱性ハンドリング
オープンソースソフトウェア(OSS)のバグや脆弱性についてよく語られていたことに、Linuxの開発者Linus Torvaldsにちなんで名付けられた「ライナスの法則」というのがあります。曰く、“given enough eyeballs, all bugs are shallow.” 直訳すれば「目玉がたくさんあればどんなバグも大したことはない」というものです。これは、OSSはソースが公開されているが故に多くの技術者の目にさらされてバグや脆弱性はどんどん潰れるというものであり、企業が責任持ってサポートする(つまりバグや脆弱性に責任持って対処する)プロプライエタリなソフトウェアに対し、OSSはその品質を保てるのか？という批判に対する答えとしてよく語られたものでした。しかし、今回の一連の事案はそのライナスの法則が成り立っていないことを明らかにしました。例えばHeartbleed Bugは、OpenSSL開発チームに対し2011年末外部から提供され取り込まれたソースコードに起因するのですが、その際、比較的単純なバグであるにも関わらず見過ごされて取り込まれ、さらに2年以上に渡って誰も気づきませんでした。CCS Injection脆弱性はそれよりは分かりにくいバグではありましたが、OpenSSL内に16年間も潜んでいたことが分かっています。さらに、bashのShellshock脆弱性に至っては、25年間もbash内で使われていた機能に残っていた、あまりにも単純かつ重大な脆弱性です。つまり、誰かが真剣にセキュリティ検査をしない限りは、広範に使われるOSSといえども脆弱性は見過ごされてしまう、「目玉の数だけでは脆弱性対策には十分ではない」ということを示しています。OSSの脆弱性検査のための何らかのインセンティブを社会は必要としていると感じます。上記の脆弱性のうちHeartbleedとPOODLEはGoogleの研究者によって発見されたのですが、彼らがOSSを社内で多く利用するが故なのかそれとも大企業として社会的責任を果たした結果なのかは分かりません。Shellshock脆弱性はフランスの一技術者Stephane Chazelasが発見したのですが、この社会的に大きな貢献に対し彼は何を得るだろうかと思うと少し考え込んでしまいます。
同時に、OSSは米国の寄付文化および「自分で何とかする」というハック文化とともに成長したものだと感じていますが、世界的にはフリーライダーが大勢であるためにシステムがうまく回っていないというのも改めて感じました。経済的にはOSSは多くが寄付で成り立っていますが、Heartbleedに関してはOpenSSLの開発体制が経済的にも人的にも極めて脆弱であることが話題になりました。また、OSSは通常利用条件に「自己責任(At your own risk)」が明記されており、利用する際にはその内容を技術的に把握しておく必要がありますが、Struts1を巡る対応を見ていると利用者によっては比較的簡単な脆弱性対応すら出来ない(つまり内容を把握していない)という様子が見られました。私は自治体などにも関わっている関係上公共における情報システム調達にも関わっていますが、その中でOSSをどう位置づけるのか、これを機にきちんと議論しておかないと電子政府・電子自治体の信頼性を保てないと感じます。
2 プロトコル規格上の脆弱性への対応
規格上・仕様上の危殆化が比較的ゆっくり進む暗号アルゴリズムに比べると、暗号を伴う通信プロトコルは突然深刻な脆弱性が明らかになることがあり、対処に困難が伴います。今回でいうとDNSへの移転インジェクション攻撃にかかる仕様上の欠陥と、SSL3.0のパディング処理があります。SSLに関してはTLSへの置き換えがゆっくりですが始まっているので比較的対処しやすいですが、DNSの仕様上の欠陥は現在のDNS運用のあり方にも絡むため解決は容易でないでしょう。そもそも通信プロトコルは、セキュリティ要求を十分に満たしているのが理想ですが、現状は規格制定プロセス上セキュリティ検査はどうしても付随的なものになりがちで、見過ごされる可能性は否めません。通信プロトコルそのものを形式的仕様に落として脆弱性検査を自動化する研究も随分進んでいるのですが、規格制定の現場にはなかなか取り入れられていないのが現状です。となると、現在使われている多くの通信プロトコルにもまだまだ脆弱性が見つかりかねないのですが、OSSの場合と同様に安全性向上のインセンティブは全体の経済原理の中ではなかなか働きません。そもそも国際的な通信規格制定の場は多分に政治力学が働く世界ですので、時にセキュリティの確保という課題は(皆が口にするものの現実は)霞みがちです。このような中で、どうやって通信の信頼性、安全性を確保していくのかというのは悩ましい限りです。
我が国では、通信プロトコルに対する脆弱性の検証とその結果の広報を組織的に行うために、暗号プロトコル評価技術コンソーシアム(CELLOS)が立ち上がっています。このような活動を通じて、暗号化プロトコルの信頼性確保が進むことを望んでいます。私も多少お手伝いしておりますので、よろしければホームページなどをご覧頂ければと思います。
暗号プロトコル評価技術コンソーシアム
https://www.cellos-consortium.org/jp/
3 脆弱性の広報と対応人材の問題
それにしても今回のこの大きな脆弱性による騒ぎは、各所の情報システムの中でどのようなリスクがあるのか正しく判断し、脆弱性に的確に対応するための人材がもっと必要であると感じさせられました。これも大きく言えばセキュリティ人材の課題であると同時に、脆弱性の広報の問題ではないかとも感じました。例えば、OpenSSLとStruts1の脆弱性は一般の新聞社にも比較的大きく報道されましたが、それより遙かに大きく深刻な脆弱性であるshellshock脆弱性は、一般紙での報道があまり大きくなかったように感じます。もちろん、各情報システム管理者にとって脆弱性情報の入手経路は一般紙以外にきちんと確保しておく必要があるのですが、技術的な評価が十分出来ない人ほど一般紙の報道にリスク評価を頼ってしまっているのではないかと心配になりますし、なにより善し悪しは別としてマスコミ報道のあり方によって経営陣の反応が大きく変わってきます。社会的なインパクトが大きいソフトウェア脆弱性の広報には、一般紙もっできるだけ参加して欲しいと思うのは、無い物ねだりに過ぎるでしょうか？
今年もまだ2ヶ月ちょっと残っていますが、年末の忙しい時期にこれ以上の大きなソフトウェア脆弱性が出てこないことを祈っています。また、「今年は当たり年」という生やさしいものではなくて、来年以降はさらに脆弱性が多く発見されて単に今年が「節目」であった、なんてことになりませんように。
【著作権は、上原氏に属します】
