質問内容

Javaの脆弱性はものすごい数上がっていますよね？具体的にどんな脆弱性があるんですか？
どういう風に攻撃されるのかも予測がつかないので、具体的に教えていただけると嬉しいです。

CVE(?)とかで報告されているJava自体の脆弱性とはどんなものがあるのか、教えていただきたいです。

背景

Javaをプログラミング言語として利用しています。
「java cve」などと検索して、以下のようなサイトに行っても、「ネットワーク越しに攻撃されるのかな？」程度にしかわかりません。
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3289

知りたいことは、

どんなコードを書いたら脆弱性になるか
どこにある脆弱性なのか（Javaの標準ライブラリあるのですか？）
具体的な攻撃方法

攻撃方法に関して記述できない場合はしょうがないです。
ですが、具体的な攻撃のイメージがわかないことが、Javaの脆弱性に対する理解が妨げにもなっています。

知識

説明していただけるときの、参考になれば幸いです。

Java SE（？）を使っている（SEとかあまりわかっていません）
java.net.ServerSocketを使ったことはある
これでも恥ずかしながらセキュリティスペシャリストの資格がある

行動規範の内容に同意します

回答4件

ベストアンサー

Javaの脆弱性で多いのは、サンドボックスという機能に関するものです。
Javaが出た当初、Javaアプレットというものがよく使われていました。これは、Javaのプログラムをブラウザ上で動作させるための仕掛けです。
インターネット上のウェブサイトに置かれたプログラムが勝手に動作すると、非常に危険です。たとえば、悪い人が作ったプログラムが、パソコンのローカルファイルの内容を読み書きできると、情報が簡単に漏洩します。このため、アプレットからはJavaのごく一部の機能だけが利用できるように制限されています。この制限機能のことを「サンドボックス」といいます。
このサンドボックス機能にしばしば脆弱性があり、「アプレットからはできないはずのことができてしまう」というのが、Javaの脆弱性の典型例です。この種の脆弱性は、ウェブサイト上の「ウイルスに感染する仕組み」として悪用されることが多く、「サイトを閲覧しただけでウイルスに感染する」という結果をもたらします。ただし、パソコン側でJREを無効化していたり、JREの脆弱性のないバージョンを使っている場合は問題ありません。
ウイルス感染が心配なのでJREを無効化しましょう、という意見がありますが、これは上記のような文脈からです。

追記します。
サーバー側でのJava本体の脆弱性による侵入というのは、あまりないと思います。
NTTデータ先端技術株式会社にて、さまざまな脆弱性の侵入実験を公表していますが、Javaに関するものは、すべて端末側で脆弱性が動いています。

site:www.intellilink.co.jp/article/vulner/ java - Google 検索

サーバーに関係するものとしては、古いですが、UTF-8の非最短形式の扱いに関するものがあります。

参考: 文字コードの脆弱性はこの3年間でどの程度対策されたか?

この問題は、Java SE 5 Update 17 および Java SE 6 Update 11 で修正されています。
一応これはJavaの脆弱性として認識されているものですが、アプリケーション側でも対処は可能で、Javaとアプリケーションのどちらに責任があるかというと、グレーゾーンに属すると思います。

投稿2017/02/12 05:56

編集2017/02/12 22:24

ockeghem

総合スコア11701

grovion

2017/02/12 08:07

ご回答ありがとうございますご丁寧な説明ありがとうございます。Javaのアプレットで、 > パソコンのローカルファイルの内容を読み書きできると、情報が簡単に漏洩とかの話は耳にしたことがあります。 > Javaの脆弱性で多いのは、サンドボックスという機能に関するものです。ということはほとんどがアプレット関連ということですか？「アプレット=問題のあるやつ」という認識が浸透している時期にJavaでのプログラミングをし始めたので、アプレット以外にもJavaの脆弱性に関することをお聞きできたらうれしいです。

grovion

2017/02/13 02:53

追記とても感謝します。 > Javaとアプリケーションのどちらに責任があるかというと、グレーゾーンに属すると思います。確かにそう思いましたぼくの理解では、以下のコードは ```java new String("..À¯..À¯bo".getBytes("ISO-8859-1"), "UTF-8") ``` （"..À¯..À¯bo"はスライド内ではfileBodyです）文字コードが「ISO-8859-1のbyte配列」を「UTF8のbyte配列」だと思って文字列にしているということですよね。これは利用者（プログラマ）の使い方の問題に思えました。しかし、JavaのUpdateでこの問題を修正しているということが知れて、「こういう脆弱性を生みそうなところをつぶすこともやっているんだな」と思いました。ちなみに、ここのページに来ていただいた方に、コードの実行結果はこうなりました。 ```java new String("..À¯..À¯bo".getBytes("ISO-8859-1"), "UTF-8") => ..��..��bo ``` 文字化けの?みたいなのが、混ざっています。どうやってbyte列からダメな文字を識別しているか少し疑問ですが、その疑問で、実際にJava(?), JDK(?)のソースの差分を見ればいいのかなと思いました。ちなみに、Javaのバージョンは修正はとっくしてある $ java -version java version "1.8.0_65" Java(TM) SE Runtime Environment (build 1.8.0_65-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode) $ javac -version javac 1.8.0_65 です

ockeghem

2017/02/13 13:06

>文字コードが「ISO-8859-1のbyte配列」を「UTF8のbyte配列」だと思って文字列にしているということですよね。 >これは利用者（プログラマ）の使い方の問題に思えました。いや、そこが問題ではありません。これは、Servlet等で、UTF-8形式の文字列を受け取る古い書き方であり、古いだけでここ単体では問題ありません。問題は、getNameeメソッドを読んでから文字コードの処理をしているところで、正しい手順は、文字コードの処理をしてからgetNameメソッドを呼ぶべきところです。「アプリケーションの責任」というのは、このことです。ただ、この種の間違いにより、TomcatやIIS等著名ソフトが脆弱性を作り込んでいるので、文字コードの変換処理側でも対処すべきだという流れになっており、主要な言語ではすべて対応しているはずです。

行動規範の内容に同意します

redstoneさんはじめ、皆さんも御存知とは思いますが。念のため。自分自身の備忘録としても。

ISECのサイトです。

https://www.ipa.go.jp/security/awareness/vendor/programmingv1/a03.html

投稿2017/02/13 00:05

say_you2001

総合スコア40

grovion

2017/02/13 02:58

say_you2001さんありがとうございますちなみに、ぼくはそのサイト知らなかったです。質問が分かりにくいのですが、「Javaで作った自分のシステムが脆弱性」ではなく「Java自体が持っている脆弱性」が知りたかったです。

行動規範の内容に同意します

無数にあると思しき脆弱性の中のたった一つだけですが説明して見ます

Javaのデシリアライズ脆弱性について

上のリンクにあるデシリアライズ時にコードが実行されるというのは実際には恐らく以下のコードでクラスυがデシリアライズされた時の状態です実行するとυのスーパークラスであるΞのコンストラクタが実行されているのが分かります

別のクラスを継承したクラスをインスタンス化しシリアライズする場合、スーパークラスがSerializableをimplementsしていればそれを継承しているクラスのオブジェクトをシリアライズした後デシリアライズしてもコンストラクタは実行されません

しかし、サブクラスのみがSerializableをimplementsしていてそのサブクラスをインスタンス化しシリアライズする場合、デシリアライズ時にスーパークラスのコンストラクタが実行される事になります

データを転送するためにオブジェクトをシリアライズして送っているものを受け取る場合、以上のように
Serializableをimplementsしているが、スーパークラスはSerializableをimplementsしていないクラスのインスタンスがシリアライズされて送られて来た場合、デシリアライズする時にこのスーパークラスのコンストラクタ内のコードが実行されるのでその中に書かれた攻撃のコードが実行される可能性があるため、シリアライズされたデータを受け取ってデシリアライズする時には基本的に攻撃用コードが実行される事を常に予期していなければならない

これは、どういうコードを書くと脆弱性を突かれるという問題ではなく、

Javaのシリアライズされたデータ全てがこの脆弱性を持つので、受け取ってデシリアライズする際にこの脆弱性を突かれた場合の対策を常にデシリアライズする側のコードに組み込んでおく必要がある

という事だと思います

java
1import java.io.*;
2class EA2{
3
4public static void main(String[] args){
5System.out.println("----υのオブジェクト生成----");
6υ obj = new υ();
7System.out.println("----υのオブジェクト生成終了----");
8System.out.println("----τのオブジェクト生成----");
9τ obj2 = new τ();
10System.out.println("----τのオブジェクト生成終了----");
11
12  try (ObjectOutputStream o = new ObjectOutputStream(new FileOutputStream("obj.txt"));
13         ObjectInputStream i = new ObjectInputStream(new FileInputStream("obj.txt"))){
14      o.writeObject(obj2);
15      System.out.println("\nτのシリアライズ及び書き込み終わり\n");
16      τ re2 = (τ)i.readObject();
17      System.out.println("\nτの読み込み及びデシリアライズ終わり\n");
18      System.out.println(re2.cont);
19
20      System.out.println("-------------------------------------------------------------");
21
22
23      o.writeObject(obj);
24      System.out.println("\nυのシリアライズ及び書き込み終わり\n");
25      υ re = (υ)i.readObject();
26      System.out.println("\nυの読み込み及びデシリアライズ終わり\n");
27      System.out.println(re.cont);
28
29    } catch (Exception e){
30      e.printStackTrace();
31    }
32
33}
34}
35
36//----------------------------------------------------------
37class Ξ{
38
39Ξ(){
40System.out.println("Ξのコンストラクタ");
41
42}
43
44}
45
46class υ extends Ξ implements Serializable{
47
48String cont="オブジェクト内内容";
49
50
51υ(){
52System.out.println("υのコンストラクタ");
53}
54
55}
56
57//---------------------------------------------------------
58
59
60class η implements Serializable{
61η(){
62System.out.println("ηのコンストラクタ");
63
64}
65}
66
67class τ extends η{
68String cont="オブジェクト内内容";
69
70τ(){
71System.out.println("τのコンストラクタ");
72
73}
74}

投稿2017/02/12 04:32

退会済みユーザー

総合スコア0

grovion

2017/02/12 05:13

tetratailさんご回答感謝いたしますこのページに来た人のためとぼくが将来確認したくなるかもしれないので、実行結果をteratailさんコードの実行結果を載せさていただきます。 ``` ----υのオブジェクト生成---- Ξのコンストラクタ υのコンストラクタ ----υのオブジェクト生成終了---- ----τのオブジェクト生成---- ηのコンストラクタ τのコンストラクタ ----τのオブジェクト生成終了---- τのシリアライズ及び書き込み終わり τの読み込み及びデシリアライズ終わりオブジェクト内内容 ------------------------------------------------------------- υのシリアライズ及び書き込み終わり Ξのコンストラクタ <<<<< [勝手に追記]　ここが大事なところですか？対応コード：υ re = (υ) i.readObject(); υの読み込み及びデシリアライズ終わりオブジェクト内内容 ``` 理解できたか、自信ありませんが、上記の「ここが大事なところですか？」のところが >> スーパークラスのコンストラクタ内のコードが実行されるが起こってるところであっていますか？ * 脆弱性のあるコードがスーパークラスのコンストラクタに書いてない限り、大丈夫ではないんですか？ * ライブラリにコンストラクタに脆弱性を持ったクラスと組み合わせて、攻撃するのでしょうか？ * または、スーパーコンストラクタがデシリアライズ時に呼ばれることが想定外で、脆弱性を作ってしまうのでしょうか？理解できたか、自身がないので、わかりませんが、 Java自体にある脆弱性というよりも、Javaの安全でないかもしれないコーディングのような気がしてしまいます。

退会済みユーザー

2017/02/12 05:18

>上記の「ここが大事なところですか？」のところが >> スーパークラスのコンストラクタ内のコードが実行されるが起こってるところであっていますか？そうです　 >脆弱性のあるコードがスーパークラスのコンストラクタに書いてない限り、大丈夫ではそう言えばそうですね　 >Java自体にある脆弱性というよりも、Javaの安全でないかもしれないコーディングのような気がそういえばそうですね　僕もこの脆弱性を使って攻撃する方法など思いつかないので >Javaの安全でないかもしれないコーディングに過ぎないのかも知れません

行動規範の内容に同意します

Java セキュアコーディングスタンダード CERT/Oracle 版

投稿2017/02/12 03:44

carimatics

総合スコア740

grovion

2017/02/12 03:55

有益なリンクのご提供ありがとうございます一覧でまとまっていて、とてもわかりやすいサイトで、ありがとうございますまだ目を通し感じですと、安全に考慮した書き方ですよね。勝手な推測ですが、CVEで公表される脆弱性は、安全に書いていても防げなく、Javaの最新版や今後のリリースで改善されるもので、Java自体が持つ脆弱性だと思うのですが、あっていますか？または、Javaの標準ライブラリのコードのが提供していただいたリンクに反する書き方により起こる脆弱性を抱えていることがあるということでしょうか？

ockeghem

2017/02/12 04:22

redstoneさんのご指摘のように、参照先のドキュメントは、Javaの使い方による脆弱性の問題で、Java自体の脆弱性の話ではないと思います。

carimatics

2017/02/12 05:01 編集

すみません、質問を勘違いしてました。 Java自体の脆弱性に関しては私もよく分からないです。軽く調べた感じだと攻撃が成立するような例は見当たりませんでした。探し方が悪いだけかもしれませんが…。概要以上のことを知るにはソースコードを読むとかメーリングリストを購読するとかしないといけないんですかね…。

grovion

2017/02/12 05:17 編集

> 軽く調べた感じだと攻撃が成立するような例は見当たりませんでした。探し方が悪いだけかもしれませんが…。ぼくも同じで、探し方が悪いのかもしれないですが、見つけられなくて。でもJavaとかFlashとか脆弱性だらけなことを聞くので、長い間の疑問です。誤解のある内容だとわかったので、質問タイトルと内容を修正します

行動規範の内容に同意します

あなたの回答