Loading article…
Javaソフトウェア プラットフォームは、 Java アプリケーションのセキュリティを向上させるために設計された多数の機能を提供します。これには、 Java 仮想マシン(JVM)の使用による実行時制約の強制、信頼できないコードをオペレーティング システムの残りの部分からサンドボックス化するセキュリティ マネージャ、Java 開発者が利用できるセキュリティAPIスイートが含まれます。それにもかかわらず、JVM のセキュリティ脆弱性を露呈する悪意のあるプログラムが増加し、その後 Oracle がタイムリーに適切に対処しなかったため、プログラミング言語と Oracle に批判が向けられています。
セキュリティ機能
JVM
Java プラットフォームで実行されるプログラムのバイナリ形式は、ネイティブ マシン コードではなく、中間バイトコードです。JVMは、このバイトコードを実行する前に検証を実行し、プログラムが誤った場所に分岐するなど、命令ではなくデータを含む可能性のある安全でない操作を実行しないようにします。また、JVM は、配列境界チェックなどの実行時制約を適用することもできます。つまり、Java プログラムは、このようなメモリ安全性の保証を提供しない Cなどの言語で書かれたプログラムよりも、バッファ オーバーフローなどのメモリ安全性の欠陥の影響を受ける可能性が大幅に低くなります。
このプラットフォームでは、ポインタ演算や未チェックの型キャストなど、潜在的に安全でない操作をプログラムが実行することはできません。メモリの割り当てと初期化を管理し、自動ガベージ コレクションを提供するため、多くの場合 (すべてではありませんが) 開発者は手動でメモリを管理する必要がなくなります。これにより、型の安全性とメモリの安全性が向上します。
セキュリティマネージャー
このプラットフォームは、信頼できないバイトコードを「サンドボックス」環境で実行できるセキュリティ マネージャーを提供します。このセキュリティ マネージャーは、信頼できないコードが特定のプラットフォーム機能や API にアクセスするのを防ぐことで、悪意のあるソフトウェアや不適切に記述されたソフトウェアからユーザーを保護するように設計されています。たとえば、信頼できないコードがローカル ファイル システム上のファイルの読み取りや書き込みを行ったり、現在のユーザーの権限で任意のコマンドを実行したり、通信ネットワークにアクセスしたり、リフレクションを使用してオブジェクトの内部プライベート状態にアクセスしたり、JVM を終了させたりすることが防止されます。
セキュリティ マネージャーを使用すると、Java プログラムを暗号で署名することもできます。ユーザーは、信頼できない状況でも、信頼できるエンティティからの有効なデジタル署名を持つコードを完全な権限で実行することを許可するように選択できます。
ユーザーは、さまざまなソースからのプログラムに対してきめ細かなアクセス制御ポリシーを設定することもできます。たとえば、システム クラスのみを完全に信頼し、特定の信頼できるエンティティからのコードには特定のファイルの読み取りを許可し、その他のすべてのコードは完全にサンドボックス化するように決定できます。
セキュリティAPI
Javaクラス ライブラリは、標準の暗号化アルゴリズム、認証、安全な通信プロトコル など、セキュリティに関連する多数の API を提供します。
Javaアプリケーションにおけるセキュリティ脆弱性の潜在的な原因
Java アプリケーションには、セキュリティ上の脆弱性の原因となる可能性のあるさまざまな要因があります。その一部は非 Java アプリケーションに共通であり、一部は Java プラットフォームに固有のものです。(これらは、セキュリティを重視するプログラマーが留意する必要がある潜在的な脆弱性の原因を指していることに注意してください。これは、実際の脆弱性のリストとして意図されているものではありません。)
Java アプリケーションと非 Java アプリケーションに共通する潜在的な脆弱性の原因の例は次のとおりです。
- アプリケーションがセキュリティ上依存しているハードウェアまたはオペレーティングシステムが提供する保護メカニズムの脆弱性
- アプリケーションやランタイムを実装するために使用される可能性のあるC標準ライブラリなどのネイティブライブラリの脆弱性
- ユーザー プログラムのエラーによってのみ発生する脆弱性 (たとえば、SQLクエリの不適切な構築によりSQL インジェクションの脆弱性が発生する)
ただし、Java セキュリティに関する多くの議論は、Java プラットフォームに固有の脆弱性の潜在的な原因に焦点を当てています。これには次のものが含まれます。
- サンドボックス機構の脆弱性により、信頼できないバイトコードがセキュリティマネージャによって課せられた制限を回避できるようになる。
- アプリケーションのセキュリティ上依存するJavaクラスライブラリの脆弱性
Java プラットフォームの脆弱性によって、必ずしもすべての Java アプリケーションが脆弱になるわけではありません。たとえば Oracle によって脆弱性とパッチが発表される場合、その発表には通常、影響を受けるアプリケーションの種類の詳細が含まれます (例)。
たとえば、特定の JVM 実装のセキュリティ マネージャー サンドボックス メカニズムにのみ影響する仮想的なセキュリティ欠陥は、任意の信頼できないバイトコードを実行する Java アプリケーションのみが侵害されることを意味します。ユーザーが実行されるすべてのバイトコードを完全に信頼し、制御するアプリケーションは侵害されません。つまり、たとえば、その JVM に基づく Web ブラウザー プラグインは、公開 Web サイトからダウンロードされた悪意のあるアプレットに対して脆弱ですが、管理者がクラスパスを完全に制御できる同じバージョンの JVM で実行されているサーバー側 Web アプリケーションは影響を受けません。[1]
Java 以外のアプリケーションと同様に、セキュリティの脆弱性は、最初はセキュリティに関連していないように見えるプラットフォームの一部から発生する可能性があります。たとえば、2011 年に Oracle は、Double.parseDoubleメソッドのバグに対するセキュリティ修正プログラムを発行しました。[2]このメソッドは、「12.34」などの文字列を同等の倍精度浮動小数点数に変換します。このバグにより、特定の入力で呼び出されると、このメソッドは無限ループに入りました。このバグはセキュリティに影響を及ぼしました。たとえば、Web サーバーがこのメソッドを使用してユーザーがフォームに入力した文字列を変換する場合、悪意のあるユーザーがバグを引き起こす文字列を入力する可能性があります。これにより、悪意のあるリクエストを処理する Web サーバーのスレッドが無限ループに入り、他のユーザーからのリクエストを処理できなくなります。脆弱な Web サーバーに対してこれを繰り返し実行すると、簡単にサービス拒否攻撃を行うことができます。ユーザー リクエストに応答するすべての Web サーバーのスレッドがすぐに無限ループに陥り、Web サーバーは正当なユーザーにまったくサービスを提供できなくなります。
セキュリティ管理者への批判
Java プラットフォームのセキュリティ マネージャー (前述のように、ユーザーが信頼できないバイトコードを安全に実行できるように設計されています) は、特にパブリック Web サイトからダウンロードした Java アプレットを実行する Web ブラウザー プラグイン (非公式には「ブラウザー内の Java」とも呼ばれます) において、ユーザーをマルウェアに対して脆弱にしているとして近年批判されています。
これらの脆弱性に対処するためのオラクルの取り組みにより、Java 8のリリースが遅れました。[3]
2012
Flashbackと呼ばれるOS Xの トロイの木馬は、Javaの脆弱性を悪用したが、Oracleはすでにパッチをリリースしていたものの、 Appleはパッチを当てていなかった。 [4] 4月に、AppleはJavaなしでLionユーザー向けに削除ツールをリリースした。 [5] Java 7 Update 4で、OracleはLion以降向けにJavaを直接リリースし始めた。[6]
10月にAppleはすべてのブラウザからJavaプラグインを削除するアップデートをリリースした。[7]これはAppleがOS XをJavaから遠ざける動きと見られていた。[8]
2013
1月には、最新バージョンのJava 7 Update 10を含むJava 7のすべてのバージョンにゼロデイ脆弱性が見つかり、すでに悪用されていました。 [9]この脆弱性は、以前の脆弱性を修正するパッチによって引き起こされました。[10]これを受けて、Appleは最新バージョンのJavaプラグインをブラックリストに登録しました。[ 11 ] Oracleは3日以内にパッチ（Update 11）をリリースしました。[12] MicrosoftもInternet Explorer バージョン6、7、8のパッチをリリースしました。[13]
サイバースパイ マルウェア「 レッド・オクトーバー」は、2011年10月に修正されたJavaの脆弱性を悪用していることが判明した。[14]国境なき記者団のウェブサイトも、Update 11より前のバージョンのJavaの脆弱性によって侵害された。[15]
アップデート11のリリース後、別の脆弱性がオンラインで広まり始め[16]、後に確認されました。[17]また、Javaのセキュリティモード自体がバグのために脆弱であることが判明しました。[18]これを受けて、MozillaはFirefoxでJava（およびAdobe ReaderとMicrosoft Silverlight）をデフォルトで無効にし、[19] Appleは最新のJavaプラグインを再びブラックリストに登録しました。[20]
2月にTwitterは攻撃を遮断したと報告した。TwitterはユーザーにJavaを無効にするよう勧めたが、理由は説明しなかった。[21]同月後半、FacebookはゼロデイJava攻撃によるハッキングを受けたと報告した。[22] Appleも攻撃を受けたと報告した。[23] iPhone開発者フォーラムの侵入がTwitter、Facebook、Appleへの攻撃に利用されたことが判明した。[24]フォーラム自体は侵入を認識していなかった。[25] Twitter、Facebook、Appleに続き、Microsoftも同様の侵入を受けたと報告した。[26]
発見された別の脆弱性により、Java 7の最初のリリース、およびUpdate 11と15でJavaセキュリティサンドボックスが完全にバイパスされる可能性がありました。 [27] 3月には、McRatと呼ばれるトロイの木馬がゼロデイJava脆弱性を悪用していることが判明しました。[28]その後、Oracleは脆弱性に対処するための別のパッチをリリースしました。[29]
参照
参考文献
- ^ CVE-2013-0422 のセキュリティアラートがリリースされました。Oracle Corporation。2013 年 4 月 24 日閲覧。
- ^ Oracle が Double.parseDouble バグの修正プログラムを記録的な速さでリリース。InfoQ。2013 年 4 月 24 日閲覧。
- ^ Secure The Train。Oracle の Java プラットフォーム グループのチーフ アーキテクト、Mark Reinhold のブログ。2013 年 4 月 18 日。
- ^ Goodin, Dan (2012 年 4 月 2 日)。「Mac Flashback トロイの木馬がパッチ未適用の Java 脆弱性を悪用、パスワード不要」Ars Technica。2014年2 月 18 日閲覧。
- ^ Geuss, Megan (2012 年 4 月 14 日)。「Flashback マルウェア除去ツールが Java 非対応の Mac ユーザー向けに登場」。Ars Technica。2014年2 月 18 日閲覧。
- ^ Foresman, Chris (2012 年 4 月 27 日)。「Apple は忘れろ: Oracle が Java のセキュリティ修正を Mac ユーザーに直接提供」Ars Technica。2014年2 月 18 日閲覧。
- ^ Goodin, Dan (2012 年 10 月 18 日)。「Apple がすべての OS X Web ブラウザから Java を削除」。Ars Technica。2014年2 月 18 日閲覧。
- ^ Cheng, Jacqui (2012 年 12 月 23 日)。「不安定な 2012 年を経て、OS X のセキュリティはどこまで進歩したか」。Ars Technica。2014年2 月 18 日閲覧。
- ^ Goodin, Dan (2013 年 1 月 10 日)。「重大な Java ゼロデイバグが「大規模に悪用されている」 (更新)」。Ars Technica。2014年2 月 18 日閲覧。
- ^ Goodin, Dan (2013 年 1 月 11 日). 「以前の不完全なパッチによって重大な Java 脆弱性が発生 (更新)」. Ars Technica . 2014 年2 月 18 日閲覧。
- ^ Foresman, Chris (2013 年 1 月 11 日)。「Apple が最新の「重大な」エクスプロイトを防ぐために OS X 上の Java をブラックリストに登録」Ars Technica。2014年2 月 18 日閲覧。
- ^ Mattise, Nathan (2013 年 1 月 14 日)。「Oracle が 3 日間で広範囲に及ぶ Java のゼロデイバグを修正 (更新)」。Ars Technica。2014年2 月 18 日閲覧。
- ^ Goodin, Dan (2013 年 1 月 14 日)。「Microsoft が Internet Explorer のバグを修正する緊急アップデートをリリース」Ars Technica。2014年2 月 18 日閲覧。
- ^ Goodin, Dan (2013 年 1 月 15 日)。「Red October は PC を感染させるために Java エクスプロイトを利用していた」Ars Technica。2014年2 月 18 日閲覧。
- ^ Goodin, Dan (2013 年 1 月 22 日)。「パッチを当てたばかりの Java と IE のバグが人権侵害サイトを罠にかける」Ars Technica。2014年2 月 18 日閲覧。
- ^ Goodin, Dan (2013 年 1 月 16 日)。「$5,000 で、新たな重大な Java 脆弱性へのアクセス権を購入できる (更新)」。Ars Technica。2014年2 月 18 日閲覧。
- ^ Goodin, Dan (2013 年 1 月 18 日)。「最新バージョンで重大な Java の脆弱性が確認される」。Ars Technica。2014年2 月 18 日閲覧。
- ^ Goodin, Dan (2013 年 1 月 28 日)。「Java の新しい「非常に高い」セキュリティ モードではマルウェアから保護できない」。Ars Technica。2014年2 月 18 日閲覧。
- ^ Goodin, Dan (2013 年 1 月 31 日)。「Firefox が Java、Reader、Silverlight に基づくコンテンツをブロック」。Ars Technica。2014年2 月 18 日閲覧。
- ^ Foresman, Chris (2013 年 1 月 31 日)。「Apple が 1 か月で 2 度目となる Java Web プラグインのブラックリスト登録」。Ars Technica。2014年2 月 18 日閲覧。
- ^ Goodin, Dan (2013年2月2日). 「Twitterが進行中のパスワードデータハッキングを検出しシャットダウン」 Ars Technica . 2014年2月18日閲覧。
- ^ ギャラガー、ショーン（2013年2月15日）。「FacebookのコンピューターがゼロデイJavaエクスプロイトによって侵害される」。Ars Technica 。 2014年2月18日閲覧。
- ^ Cheng, Jacqui (2013年2月19日). 「Apple HQもハッカーの標的、顧客保護ツールをリリース予定」 Ars Technica . 2014年2月18日閲覧。
- ^ ギャラガー、ショーン（2013年2月19日）。「Facebook、Twitter、AppleのハックはiPhone開発者フォーラムから生まれた」Ars Technica 。 2014年2月18日閲覧。
- ^ Cheng, Jacqui (2013年2月20日). 「Apple、Facebookのハッカーはそれが罠だとは知らなかった開発サイト」 Ars Technica . 2014年2月18日閲覧。
- ^ Bright, Peter (2013年2月22日)。「MicrosoftがApple、Facebook、Twitterに加わり、ハッキング被害者として名乗り出る」Ars Technica 。 2014年2月18日閲覧。
- ^ Brodkin, Jon (2013 年 2 月 25 日)。「Java の最新のセキュリティ問題: 新たな欠陥が特定され、古い欠陥が攻撃される」。Ars Technica。2014年2 月 18 日閲覧。
- ^ Goodin, Dan (2013 年 3 月 1 日)。「新たな Java ゼロデイ エクスプロイトが活発に標的を攻撃中」。Ars Technica。2014年2 月 18 日閲覧。
- ^ Mattise, Nathan (2013 年 3 月 5 日)。「Oracle が今週の McRat 問題に対処する新しい Java パッチをリリース」Ars Technica。2014年2 月 18 日閲覧。
外部リンク
- Java SE セキュリティ。Oracle Corporation。2013 年 4 月 24 日にダウンロードされました。
- Java プログラミング言語のセキュア コーディング ガイドライン。Oracle Corporation。2013 年 4 月 24 日にダウンロード。
- セキュリティ マネージャーが最小権限の原則で実行する際にどのように役立つか。