JREを狙った攻撃の新しい傾向

　当DeepSight Threat Analyst Teamがこの数週間ほどJavaの問題を何件か調査している。米サン・マイクロシステムズのJava実行環境ソフトウエアJava Runtime Environment（JRE）のセキュリティ・ホールを狙う攻撃は，別に目新しくない。これまで複数の研究者がこのテーマを取り上げ，優れた成果を上げてきた。ただこのところ，JREと関連コンポーネントに影響するセキュリティ・ホールの報告が目立って増えている。

　攻撃はクライアント側のぜい弱性を突くもので，この数年急拡大してきた。このぜい弱性を抱えるアプリケーションは，メディア・プレーヤ，Webブラウザ，ActiveXコントロール，メール・クライアント・ソフトウエアなど多岐にわたる。JREは広く普及しているため，攻撃者にとっては格好の標的となる。この背景を考えると，Java仮想マシン（JVM）のような環境への攻撃の予備研究が，最近公開されたぜい弱性や，その結果として世に広まる攻撃につながっているとしても驚くにはあたらない。JREに対する攻撃の研究は，Javaの一部がオープンソースになったことで一層増えてきている。

　サンは2007年1月16日，米3Comのバグ探しコンテストZero Day Initiativeで2006年12月に提出されたJREのセキュリティ・ホール情報を公表した。これはヒープ改変（コラプション）にかかわるぜい弱性で，幅属性0のGIF画像処理時に悪用される（Sun Java Runtime EnvironmentのGIF画像バッファ・オーバフローに関するセキュリティ・ホール）。DeepSightのハニーポット（おとり用の攻撃対象）は2007年6月26日，このセキュリティ・ホールを狙った悪意あるWebサイトから攻撃された。JREに存在するセキュリティ・ホールは今までいくつか見つかっているが，DeepSight Threat Analyst Teamが実際に確認した悪用例は非常に少なく，ハニーポットに対するこの攻撃は注目に値する。

　さらに7月3日，JREの画像処理でヒープ改変にかかわる別のセキュリティ・ホールが見つかった（Sun JDKのJPG/BMP処理に関する複数のセキュリティ・ホール）。これは，International Color Consortium（ICC）プロファイルを読み込む際の検証が不十分なために起きる問題である（ICCプロファイルとは，画像表示する際に色空間をプラットフォーム非依存で記述するデータ）。また米イーアイ・デジタル・セキュリティは7月9日，Java Network Launching Protocol（JNLP）ファイル処理時に起きるスタック・オーバーフローを発見した（Sun Java Runtime Environment WebStart JNLPスタック・バッファ・オーバフローに関するセキュリティ・ホール）。このセキュリティ・ホールは，codebaseパラメータ処理時に境界（割り当てられたメモリーの範囲）をチェックしていないことが原因である。このようにJREのセキュリティ・ホールが急に登場してきたことから，今のJavaセキュリティの実態が垣間見える。これらの問題は攻撃についての研究が，JREを狙う，より現代的なものに移行（または，少なくとも問題発覚の増加）していることを意味している。

　JREに存在するセキュリティ・ホールで最も関心を集める点の一つは，うっかり攻撃者にセキュリティ・ホールの悪用手段を与えてしまったことだろう。まず真っ先に挙げられるのは，JRE関連のぜい弱性を突く際に絶好の媒体となるJavaアプレットである。アプレットを使うと，悪意あるWebサイトを介して攻撃コードを配信し，JREのぜい弱性を突く“ドライブバイ”攻撃が容易になる。アプレットは，IFRAMEで隠したり，サイズを小さくしてWebサイトの目立たない場所に配置したりすることが簡単に行えるので，なかなか気付かれない。

　二つ目はJavaのヒープ・メモリー割り当て方法に起因する項目で，攻撃者がヒープに繰り返し大量のNOP Sledを書き込み，メモリーの広範囲に関連ペイロードを埋め込むことで攻撃の成功率を高める，というシナリオだ。元々この攻撃手法は，「Skylined」という名称のグループがWebブラウザのぜい弱性を攻撃する目的でJavaScriptで使うように考案したものである。しかし，これと似た手法はJRE内でも同様に利用できることが実証されている（JvmGifVulPoc.javaを参照）。さらにヒープに戻ることで，攻撃者は（特にスタック・オーバフロー関連セキュリティ・ホールの場合は）Windows XP SP2が備えているセキュリティ機構（DEPやSafeSEH）の多くを回避できてしまう。このセキュリティ機構を確実に避ける能力によって，これらのぜい弱性への攻撃がより魅力的になっている。

　この種の攻撃を緩和する解決策は，以前から存在する一般的なやり方である。一番大切なのは，できるだけ新しい修正パッチで常にJavaを最新状態とし，侵入防止システム（IPS）と侵入検知システム（IDS）のシグネチャも更新し続けることだ。信頼していないWebサイトを閲覧する際は警戒を怠らず，必要のない限りJavaやJavaScript，そのほかの動的コンテンツを無効化しておく（Firefoxには，この無効化を簡単に行える素晴らしい拡張機能「NoScript」がある）。

　JREに影響する不具合の研究は，別に目新しいわけではない。ただ，これを悪用する例が現実のものになり始めている。MPackのような攻撃ツールは効率的であり，クライアントに存在するぜい弱性を何度でも危険にさらす（関連記事：「MPack：大量ハッキング・ツールの変わった例」）。ファイル・フォーマットの解析は本質的に複雑なので，ここで紹介した種類のバグはなかなか修正しきれないし，Javaも例外ではない。

　さらに我々は最近，米マイクロソフトの.Net Frameworkについて，注目すべき3件のセキュリティ・ホールが公表されたことを確認した。特にこのうちの2件は興味深い。具体的には，Microsoft .Net Framework PEローダーの遠隔バッファ・オーバーフローのセキュリティ・ホールと，Microsoft .Net Framework JITコンパイラの遠隔バッファ・オーバーフローのセキュリティ・ホールで，JREで明らかにされたのと同種のバグを連想させる。.Netに同様のセキュリティ・ホールを見付けるレースが繰り広げられていることは想像に難くない。

Copyrights (C) 2007 Symantec Corporation. All rights reserved.

本記事の内容執筆時点のものであり，含まれている情報やリンクの正確性，完全性，妥当性について保証するものではありません。

◆この記事は，シマンテックの許可を得て，米国のセキュリティ・ラボの研究員が執筆するブログSecurity Response Weblogの記事を抜粋して日本語化したものです。オリジナルの記事は，「New Trend in Attacking the Java Runtime Environment?でお読みいただけます。