高木浩光＠自宅の日記

■ 続・厚生労働省の脆弱性放置は何が問題とされているのか

一昨日の日記の続き。結論から言うと、今日気付いた事実により、一昨日の最後の節「Sun Microsystemsの愚行」は取り消さねばならない。その問題は昨年既に解決されていた。したがって、電子政府でとるべき措置も明確になった。

目次

• JREの脆弱性には2つのタイプがある
• 「電子申請システムを利用するにあたっては問題ありません」が嘘になる場合
• JRE組み込みのアプリケーション開発という方法
• Java Updateしても古いJREが消えない問題
• ファミリバージョン指定という5.0 Update 7以降の機能
• 電子申請システムを安全かつ便利にするため今なすべきこと

JREの脆弱性には2つのタイプがある

まず、JREの脆弱性とは何かを確認しておく必要がある。JREの脆弱性には大別して2つのタイプがある。sandboxの柵が破れる脆弱性と、それ以外の脆弱性である。

Javaは汎用のプログラミング言語であり、JavaScript等と違って、直接ファイルを操作する等の機能がはじめから用意されている。一方で、JREには、Webページ上に貼り付けられたJavaプログラム（Javaアプレット）をWebブラウザ上で実行する機能（Java Plug-in）がある。もし、Javaアプレットにファイルを操作するコードが書かれていたら、Webページを閲覧しただけで、勝手にファイルを消されたり盗まれたりすることになりかねない。そこで、そうした危険性を持つ機能がWebページ上からでは呼び出せないよう、Javaにはセキュリティチェックする機能が組み込まれている。これが「sandbox」と呼ばれる仕組みで、外に出られないようにした砂場の中で子供（Webページ上のプログラム）を遊ばせておく*1というものだ。

sandboxに穴が開いていて外に出る方法が存在していると、それはセキュリティホール（脆弱性）ということになる。言語システムにはしばしば予見できなかった設計上の不備や実装上のミスがあるが、それが最終的にsandboxの破れにつながることが発見されると、それは通常のバグとは別扱いで優先的に修正措置がとられて更新版がリリースされることになる。過去のJREの脆弱性報告を見ると、年に1回はこのタイプの脆弱性が修正されていることがわかる。

JREに見つかる脆弱性の大半はこのsandboxの破れのタイプである。そのため、電子申請システムの注意喚起の文では、しばしば次のような言い方がされて（コピペで広がって）いる。

国家公務員共済組合連合会電子申請を利用する際に必要なJREにセキュリティホールが発見されました。

当該セキュリティホールは、JREに存在するセキュリティホールであり、国家公務員共済組合連合会電子申請システムに関するセキュリティホールではないので、国家公務員共済組合連合会電子申請システムを利用するにあたっては問題はありません。

しかし、国家公務員共済組合連合会電子申請システムを利用するためにJREを有効にしている場合、悪意あるwebサイトを閲覧した場合にJREのセキュリティホールを攻撃され被害を受ける可能性があります。

JREの脆弱性について, 国家公務員共済組合連合会

この説明は、sandboxの破れタイプの脆弱性の説明としては間違っていない。しかし、もう一つのタイプの脆弱性（が見つかった場合）の説明としては正しくない可能性がある。

「電子申請システムを利用するにあたっては問題ありません」が嘘になる場合

もう一つのタイプとは、例えば、言語システム上にバッファオーバーフロー脆弱性が見つかった場合などだ。実際、先月末に公表された最新のJREの脆弱性「JVNVU#138545 JRE (Java Runtime Environment) のイメージ解析コードにバッファオーバーフローの脆弱性」がそれに該当する。Javaで書かれたコード自体はバッファオーバーフローを引き起こすことはないが、Javaの言語機能やライブラリの一部は、最終的にnativeコードである（C言語で書かれている）ので、その部分にバッファオーバーフロー系の脆弱性が存在し得る。

このタイプの脆弱性がある場合、Javaアプレットでないところで被害が出る危険性があることに注意しなければならない。例えば、standaloneプログラムとしてJavaで書かれたワープロソフトがあるとしよう。そのワープロは拡張子「.rtf」（リッチテキスト形式）のファイルをダブルクリックすると起動するように設定されているとする。その場合、誰かから送られてきた「.rtf」ファイルを開いたときに、そのファイルに攻撃コードが仕込まれていると、被害が出ることになる。

これは、ファイルを開いた人が悪いのだろうか？ たしかに、拡張子「.exe」のファイルを開くのは開く人が悪いのであって、何かの脆弱性ではない。しかし、拡張子「.rtf」はプログラムコードを含まないファイル形式である（ことがコモンセンスである）ので、本来、どんなファイルであっても開いてかまわないもの（どんなWebページにアクセスしてもかまわないのと同様に）である。同様に「.pdf」もそうであるし、「.doc」も近頃はMicrosoft Wordがマクロ機能をデフォルト無効にしたことからその部類のファイル形式となった。*2

このような考え方は昨今確立してきたので、その前提が崩れるものは脆弱性とみなされる。実際、一太郎にバッファオーバーフロー脆弱性があり、ゼロデイ攻撃により標的型攻撃の実害が発生という事例が何度か出ているが、これらは、一太郎形式のファイルを開いたときに発動する問題であり、開いてかまわないはずの拡張子のファイルを開いたときにプログラムコードが実行される不具合であることから、セキュリティ脆弱性と認定されている。

• JVN#90815371 一太郎におけるバッファオーバーフローの脆弱性, JVN, 2006年10月18日
• 一太郎の脆弱性を悪用した不正なプログラムの実行危険性について, ジャストシステム, （公表日不明）*3
• 一太郎の脆弱性を悪用した不正なプログラムの実行危険性について, ジャストシステム, 2007年4月*4

したがって、「JVNVU#138545 JRE (Java Runtime Environment) のイメージ解析コードにバッファオーバーフローの脆弱性」は、Javaで書かれたワープロに影響するだろう。「当ワープロを利用するにあたっては問題はありません」というわけにはいかない。

では、巷の電子申請システムはこの脆弱性（JVNVU#138545）の影響を受けるだろうか。その判断は簡単ではない。悪意ある者によって作られた画像を表示する場面があるかどうかだ。

申請者が自分で作成したファイルを閲覧することについては問題にならない。官側が提供した画像が悪意あるものであると申請者側に被害が出るが、そういうことはないことになっている。強いて言えば、官側で未知のウイルス感染が広がっている場合に、それが申請者側に提示されて、申請者に被害が出るということを想定すると、JREの脆弱性が電子申請システムにおいても影響を及ぼすと言えなくもない。

もう一つは官側の被害が考えられる。すなわち、悪意ある申請者が、JREのバッファオーバーフロー脆弱性を突く画像ファイルを申請したときに、官側の受理作業者の端末がJavaで作られた閲覧システムを使用していると、脆弱性を突かれて被害が出る可能性がある。官側の人達は、JREの脆弱性発覚に際して、「自分達はこの端末で他所のWebサイトを見に行くことはないのだから、この脆弱性は放置しておいてかまわない」と考えているに違いないが、そうでない可能性がある。ただし、官側のシステムがどのように作られているかは不明なので、本当にそういうことになっているのかはわからない。

他にも、例えば、Javaの暗号ライブラリに暗号処理の不備が見つかった場合、それもセキュリティ脆弱性として扱われる。その暗号ライブラリを電子申請システムが使用している場合には、暗号文が解読されたり、鍵が漏れたり、中間者攻撃されるといった被害の可能性が生じたりするので、電子申請システムと専用ソフトの修正が必要になることがある。

したがって、JREの脆弱性が「いつものようにまた出た」といって、sandboxの破れタイプかどうか確認せずに、ただの一つ覚えで「電子申請システムを利用するにあたっては問題はありません」と毎回同じことを掲示するというのは、誤りである。

JRE組み込みのアプリケーション開発という方法

一昨日の日記で、「これについては後日」として、「もう一つの方法は、JRE組み込みのアプリケーションを開発して提供することだ。これにより、JREの別途インストールを不要とし、Java Plug-inにそのJREの脆弱性が影響しないようにできる」という点に触れた。

電子申請システムを運営している人達は、JREの脆弱性が発覚するたびにあのような注意喚起告知をさせられることを苦々しく思っているだろう。自分達は電子申請システムを提供したいだけなのに、JREを導入させることで関係のない一般Webサイトでの脅威が生じてしまうのは不本意だと。

ならば、別途JREインストールを必要としないアプリケーションの作り方をしたらいい。実際、法務省の「登記申請書作成支援ソフトウェア」はそのようになっている。

このソフトウェアはJavaで書かれているが、別途JREのインストールを必要としない。図1のように、このソフトウェアのインストーラによってJREは内部に組み込まれる形で配備される。このJREはWebページでのJavaに影響しない。なぜなら、この方法による組み込みではJava Plug-inのインストールは行われないからだ*5。おそらく、Sun MicrosystemsがこのようなJREの再配布形態をライセンスで認めているのだろう。

図1: 法務省の「登記申請書作成支援ソフトウェア」のインストールフォルダの様子

他にも、XLsoftのJETというAOTコンパイラを試用したことがあるが、これは、JREを含む形でコンパイル済みネイティブコードを生成するもので、購入者はその生成物を配布することが認められている。

こうした方法で電子申請用のアプリケーションを配布していれば、単独のアプリケーションにすぎないのだから、毎年発生するJREの脆弱性にいちいち対応せずに済むことになる。*6

なぜこういう方法をとらないんだろうか？

ただし、前の節で書いたように、影響を受けなくなるのは sandboxの破れタイプの脆弱性についてである。画像処理のバッファオーバーフロー脆弱性が発覚した際には、それを使って作られた単独のアプリケーションにも影響し得る。その場合は、それはJREの脆弱性というよりも、そのソフトウェア自体の脆弱性*7ということになる。影響があるかないかを自力で精査して、影響があるなら修正バージョンをリリースすることになる。

とはいえ、JREに頻繁に発覚する脆弱性の大半がsandboxの破れタイプの脆弱性なのだから、この方法にしていれば、脆弱性対応のコストは大幅に低減するのではないか。

この方法が採用されない原因の一つは、「アプレットも使っているから」ということだと思われる。どういうわけか、専用ソフトのインストールを要求しているのに、アプレットで電子申請システムが作られている官公庁が多い。

しかもそのアプレットは署名済みアプレットになっているので、アプレットは何でも実行できる。だったら、専用ソフトの事前インストールなんて必要ない。普通は、インストールさせる手間をかけさせるくらいなら専用ソフトで機能を実現し、事前準備なしに利用できるようにするならアプレットで実現するという、どちらか一方にするものだ。役所の人達は、何もわかっておらず、他がこういうことをやっているからこういうものなんだと思っているのだろう*8。

そのため、Java Plug-in（Webページ上でJavaアプレットを走らせるJREの機能）が必要となって、別途JREのインストールを利用者にさせる必要が生じている。

Java Updateしても古いJREが消えない問題

JREには数年前から「Java Update」という名の自動アップデート機能が備わっている。しかし、Windows Update等とは異なり、このJava Updateは、新しいバージョンのJREを追加インストールするだけで、インストール済みのJREを置き換える（古いバージョンを削除する）わけではない。

古いJREが残っていると、そっちを使ってJavaアプレットを起動し、残っている脆弱性を突くという攻撃の危険性がかつて指摘されていた。これは、HTMLでアプレットの貼り付けを記述するときに、次のように書くことで、任意のJREバージョンを指定できてしまう*9ためだった。（以下は JRE 1.4.2_10 での起動を指定した例。）

<object classid="clsid:CAFEEFAC-0014-0002-0010-ABCDEFFEDCBA" ...>

そのため、JREにセキュリティ修正版が出たら古いものを必ず削除するよう呼びかけが行われていた。

7 つ全てを解決するには、JDK / JRE 5.0 Update 6 以降、SDK / JRE 1.4.2_10 以降、SDK / JRE 1.3.1_17 以降に移行する。新しいバージョンを単にインストールしただけでは、昔のバージョンが残ったままとなるので、古いものについてはアンインストールすること。

セキュリティホール memo - 2006.02.08

SDK / JRE 1.4.2 Update 14、JDK / JRE 5 Update 11 で修正されている。なお、SDK/ JDK/ JRE の新しいバージョンをインストールしても古いバージョンは残りつづけるので注意されたい。古いバージョンは明示的に削除しなければならない。

セキュリティホール memo - 2007.05.10

このような状況から、例えば法務省の告知のように、「削除、削除、インストール、インストール、バッチ実行」などという、無駄に面倒な作業手順を案内する羽目になっている。

この問題がかつてあまり糾弾されてこなかったのは、Java Updateがなかった時代には、JREのアンインストールとインストールのやり直しは、利用者の意思の下で行うという建前だったからだろう。ところが、Java Update機能が搭載され、さらにタスクバーにバルーン形式で告知されるようになると、Windows Updateと同じ仕組みだと一般の人達は誤解しかねない状況になっていた。

そろそろ無視できない危険があるということで、たしかこの問題は去年あたりに騒ぎになっていた記憶がある。その後のバージョンでこの問題は解決されていたのではなかったか？ と思い、調べてみたところ、JRE 5.0 Update 6 で解決されていた。

このことはSun Microsystemsの以下のページに書かれている。（日本のサンは日本語訳を出していないようなので、ここで勝手に訳しておく。）

• Sun Alert ID: 102557, Java Plug-in and Java Web Start May Allow Applets and Applications to Run With Unpatched JRE, Sun Microsystems, 2006年8月21日
  Sun Alert ID: 102557, Java Plug-inとJava Web Startが、未パッチのJREによってアプレットやアプリケーションを走らせることを許してしまう」

  1. Impact
  影響

  The Java Plug-in and Java Web Start both allow applets and applications to specify the version of the Java Runtime Environment (JRE) to run with. However, the versions of Java Web Start and the Java Plug-in listed in Section 2 below may allow applets or applications to run with a specified version of the JRE that does not have the latest security fixes.

  Java Plug-inとJava Web Startはいずれも、アプレットやアプリケーションに対し、それを走らせるためのJREのバージョンを、明示することを許す。しかしながら、以下の第2節にリストされたJava Web StartとJava Plug-inのバージョンは、アプレットやアプリケーションに対し、指定された、最新のセキュリティ修正を施していないバージョンのJREで走らせることを許してしまう。

  2. Contributing Factors
  該当製品

  This issue can occur in the following releases (for Solaris, Linux and Windows platforms):

  この問題は、以下のリリース（Solaris と Linux、Windowsプラットフォーム用の）において起き得る。

  • Java Plug-in included with J2SE 5.0 Update 5 and earlier, 1.4.x, 1.3.1, and 1.3.0_02 and later
    J2SE 5.0 Update 5およびそれ以前、1.4.x、1.3.1 と 1.3.0_02およびそれ以前に含まれているJava Plug-in
  • Java Web Start included with J2SE 5.0 Update 5 and earlier, and 1.4.2
    J2SE 5.0 Update 5およびそれ以前と、1.4.2に含まれるJava Web Start

  • Java Web Start 1.2, 1.0.2, 1.0.1, and 1.0
    Java Web Start 1.2、1.0.2、1.0.1と 1.0

  （略）

  4. Relief/Workaround
  回避策

  To work around the described issue for the Java Plug-in on the Solaris and Linux platforms, use the latest JRE releases available from Sun and remove all symbolic links of earlier versions of Java Plug-in from the browser "plugins" directory.

  SolarisとLinuxプラットフォームのJava Plug-inにおいて、この問題を回避するには、Sunから提供されている最新のJREリリースを使い、ブラウザの「plugins」ディレクトリから、古いバージョンのJava Plug-inへのすべてのシンボリックリンクを取り除いてください。

  5. Resolution
  解決策

  This issue is addressed in the following J2SE releases:
  この問題は以下のJ2SEリリースで処理されている。

  Java Plug-in:

  • Java Plug-in 5.0 Update 6 and later for Windows
    Windowsについては、Java Plug-in 5.0 Update 6およびそれ以降

  Notes:

  1. Prior to 5.0 Update 6, an applet could specify the version of the JRE on which it would run. With 5.0 Update 6 and later installed on the Windows platform, all applets are executed with the latest version of the JRE.

  5.0 Update 6より前では、アプレットは走らせるJREのバージョンを指定できてしまう。Windowsプラットフォームで5.0 Update 6およびそれ以降がインストールされていると、全てのアプレットは最新バージョンのJREで実行される。

  2. For Solaris and Linux, please see the "Relief/Workaround" section above.

  SolarisとLinuxについては、上の回避策の節を参照のこと。

  Java Web Start:

  • Java Web Start 5.0 Update 6 and later for Windows, Solaris, and Linux
    WindowsとSolaris、Linux用のJava Web Start 5.0 Update 6およびそれ以降

  Note: Prior to 5.0 Update 6, an application could specify the version of the JRE on which it would run. With 5.0 Update 6 and later installed, unsigned Java Web Start applications that specify a version other than the latest installed will trigger a warning, requiring explicit user permission before the application will run. Signed Java Web Start applications are not affected.

  5.0 Update 6より前では、アプリケーションは走らせるJREのバージョンを指定できてしまう。5.0 Update 6およびそれ以降がインストールされていると、インストールされた最新のもの以外のバージョンを指定する未署名のJava Web Startアプリケーションは、アプリケーションが走り出す前に、利用者の明示的な許可を要求するよう警告を出す。署名済みのJava Web Startアプリケーションは影響されない。

  （以下略）

なるほどだ。これに関連する文書を読んだところ、次に出たバージョンである 5.0 Update 7 で、さらなる改良が施されていたことを知った。

ファミリバージョン指定という5.0 Update 7以降の機能

5.0 Update 5 までで可能だった「clsid:CAFEEFAC-0014-0002-0010」という指定（JRE 1.4.2_10 の使用を指定）は Update 6で不可に対策されたが、それでは厳しすぎるという苦情が出たのか、Update 7では、「clsid:CAFEEFAC-0014-0002-FFFF」という形で「JRE 1.4.2_XX」という、ファミリバージョンでの指定ができるようになっていた。

このことは次の文書に説明されている。（日本のサンは日本語訳を出していないようなので、ここで勝手に訳しておく。）

• Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer, Java SE 6 Release Notes, Sun Microsystems
  Internet Explorer用Java Plug-inにおける、JREのファミリバージョンを指定したJavaアプレットの配備

  Starting in the Java Runtime Environment (JRE) 5.0 Update 7 release, you can specify a JRE family version for a Java applet to run in Java Plug-in for Internet Explorer.

  JRE 5.0 Update 7 リリースから、Internet Explorer用のJava Plug-inでJavaアプレットを走らせる際に、JREファミリバージョンを明示的に指定できるようになりました。

  Background
  背景

  In releases prior to JRE 5.0 Update 6, you could specify exactly which JRE release to deploy with a Java applet.

  As of JRE 5.0 Update 6, you can no longer specify the exact JRE release due to the potential misuse of static versioning. Instead, all Java applets are run using the latest version of the JRE software that is installed on the system. Note that this new behavior will not change if, after installing JRE 5.0 Update 6 or a later release, you then install an earlier JRE release. For details of the related Sun Alert, see http://sunsolve.sun.com/search/document.do?assetkey=1-26-102557-1.

  JRE 5.0 Update 6がリリースされる前では、どのJREリリースでJavaアプレットを配備するかを、ズバリ明示指定することができました。

  JRE 5.0 Update 6からは、静的なバージョン指定が誤用される可能性を理由に、ズバリJREリリースを指定することはもうできなくなりました。その代わりとして、全てのJavaアプレットは、そのシステムにインストールされたJREソフトウェアの最新バージョンを用いて走ります。特筆すべきは、この新しい挙動は、JRE 5.0 Update 6およびそれ以降のリリースをインストールした後ならば、その後古いJREリリースをインストールしても、変わらないようになっているということです。関連する Sun Alertの詳細については次をご覧下さい。http://sunsolve.sun.com/search/document.do?assetkey=1-26-102557-1

  Because you can only use the latest version of the JRE software that is installed on the system to run Java applets, you must migrate your software to the latest JRE version as soon as possible.

  This change might break existing Java applets that cannot be immediately migrated to the latest JRE version. For this reason, the JRE 5.0 Update 7 release introduces an interim solution that enables these Java applets to run with a specific JRE family version. As such, you can keep your existing deployment working while migrating your Java applets to the latest JRE version. This interim solution is described in the next section.

  Javaアプレットを走らせるために、システムにインストールされたJREソフトウェアの最新バージョンだけが利用可能なので、可能な限り早く、あなたのソフトウェアは最新のJREバージョンに移行させなければなりません。

  この変更は、最新のJREバージョンへの移行が即座にできないような既存のJavaアプレットを、動かなくしてしまうかもしれません。この理由により、JRE 5.0 Update 7 リリースは、そのようなJavaアプレットが指定のJREファミリバージョンで走らせられるよう、暫定的な解決策を導入します。というわけで、あなたのJavaアプレットを最新のJREバージョンへ移行させるまでの間、あなたの既存の配備を働かせ続けることができます。この暫定的な解決策は次の節で詳述します。

  Developers and Independent Software Vendors (ISVs) who want a longer term solution of deploying Java applications through a browser to a specific JRE release might want to use Java Web Start. For information about Java Web Start, see http://java.sun.com/javase/technologies/desktop/webstart/.

  ブラウザ経由のJavaアプリケーションを指定のJREリリースで配備することを、より長期にわたってお求めの、開発者様および独立系ソフトウェアベンダ様におかれましては、Java Web Startをご利用なさってはいかがでしょうか。Java Web Startについての情報は次をご覧下さい。 http://java.sun.com/javase/technologies/desktop/webstart/.

  Specifying Family JRE Versions for Java Applets
  JavaアプレットのファミリJREバージョンを指定する

  In the JRE 5.0 Update 7 release for Java Plug-in for Internet Explorer, two new family Class IDentifier (CLSID) for <object> tags are introduced. You can use these tags to specify that the Java applet requires the JRE 1.4.2 or the JRE 5.0 family to run. In the JRE 6 release for Java Plug-in for Internet Explorer, a third new family CLSID is introduced so that you can specify that the Java applet requires the JRE 1.4.2, JRE 5.0, or JRE 6 family to run. In all releases, you cannot specify a specific release within a JRE family.

  The following table shows the family CLSID to specify for each JRE family version.

  Internet Explorer用Java Plug-inのJRE 5.0 Update 7リリースでは、<object>タグ用の2つの新たなファミリクラス識別子（CLSID）が導入されました。これらのタグを用いて、Javaアプレットに対し、JRE 1.4.2 または JRE 5.0 ファミリでの実行を指定することができます。Internet Explorer用Java Plug-inのJRE 6リリースでは、3番目の新たなファミリCLSIDが導入され、Javaアプレットに対し、JRE 1.4.2 または JRE 5.0 または JRE 6 ファミリでの実行を指定することができます。全てのリリースにおいて、JREファミリ内の特定のリリースを指定することはできません。

  以下の表は、各JREファミリバージョンのために指定するファミリCLSIDを示しています。

  JRE Family Version	Family CLSID
  1.3.1 Note that the 1.3.1 family clsid is not currently available. It will be available in forthcoming JRE 6 and JRE 5.0 update releases.	clsid:CAFEEFAC-0013-0001-FFFF-ABCDEFFEDCBA
  1.4.2	clsid:CAFEEFAC-0014-0002-FFFF-ABCDEFFEDCBA
  5.0	clsid:CAFEEFAC-0015-0000-FFFF-ABCDEFFEDCBA
  6.0	clsid:CAFEEFAC-0016-0000-FFFF-ABCDEFFEDCBA

  When a JRE family is specified, the Java Plug-in software looks for the latest release of that family that is currently installed. The Java Plug-in software prefers a release that is equal to or later than the security baseline for that JRE family.

  The security baseline consists of the version number of the latest release for each JRE family that is available when the latest JRE family is built. For example, when the JRE 5.0 Update 7 release was built, the security baseline for the 5.0 JRE family was 5.0 Update 7. For the 1.4.2 JRE family, the security baseline was 1.4.2_10. Starting with the JRE 5.0 Update 7 release, the security baseline information is included in each release of the most current JRE family.

  Suppose the following applet that uses the 1.4.2 family CLSID is launched:

  JREファミリが指定されると、Java Plug-inソフトウェアは、現在インストールされているそのファミリの最新のリリースを探します。Java Plug-inソフトウェアは、そのJREファミリのセキュリティベースラインに等しいかそれより新しいリリースを選びます。

  セキュリティベースラインは、最新のJREファミリが作成された時点で利用可能な各JREファミリの最新リリースのバージョン番号で構成されます。例えば、JRE 5.0 Update 7が作成されたとき、5.0 JREファミリのセキュリティベースラインは、5.0 Update 7でした。1.4.2 JREファミリーについては、セキュリティベースラインは 1.4.2_10 でした。JRE 5.0 Update 7のリリース以降、セキュリティベースライン情報は、現行のJREファミリの各リリースに含まれています。

  以下のようにCLSIDを指定する1.4.2ファミリを使用するアプレットを仮定してみると、

  <OBJECT
       classid="clsid:CAFEEFAC-0014-0002-FFFF-ABCDEFFEDCBA"
       width="200" height="200">
       <PARAM name="code" value="Applet1.class">
  </OBJECT>
  

  The Java Plug-in software can take one of three possible actions:

  Java Plug-inソフトウェアは、3つの可能性のなかから1つの動きをとります。

  • If one or more versions of the JRE 1.4.2 release are installed and the latest version is no older than the security baseline, the Java Plug-in software runs the applet using that release.

    1つかそれ以上のJRE 1.4.2リリースのバージョンがインストールされていて、かつ、最新のバージョンがセキュリティベースラインより古くはない場合、Java Plug-inソフトウェアは、そのリリースを用いてアプレットを走らせる。

  • If one or more versions of the JRE 1.4.2 release are installed and the latest version is older than the security baseline, the Java Plug-in software displays a warning.

    The user must click Yes to run the applet. The user also has the option of downloading the latest release.

    1つかそれ以上のJRE 1.4.2リリースのバージョンがインストールされていて、かつ、最新のバージョンがセキュリティベースラインより古い場合、Java Plug-inソフトウェアは、警告を表示する。

    利用者は、そのアプレットを走らせるには「Yes」をクリックしなければならない。また、利用者には、最新のリリースをダウンロードするオプションもある。

  • If the JRE 1.4.2 release is not installed, the Java Plug-in software offers to download its most recent version.

    JRE 1.4.2リリースがインストールされていない場合、Java Plug-inソフトウェアは、その最も新しいバージョンのダウンロードを提案する。

  Similar actions are taken for a CLSID that specifies the JRE 5.0 family when a later JRE family is released. In this case, where JRE 5.0 is the latest family JRE, the first action is taken.

  新たなJREファミリがリリースされたとき、JRE 5.0ファミリを指定するCLSIDについても同様の動作がとられる。この場合、JRE 5.0が最新のファミリJREであるとき、最初の動作が選択される。

  In some cases, you might want to detect if the family CLSID is available and then generate the <object> tag dynamically. Such detection can be done by checking the "JavaPlugin.FamilyVersionSupport" ProgID in JavaScript, as follows:

  いくつかの場合、そのファミリCLSIDが利用可能かどうかを検出した上で動的に<object>タグを生成したいことがあるかもしれない。そのような検出は、以下のように、 JavaScriptで「JavaPlugin.FamilyVersionSupport」 ProgIDをチェックすることでできる。

  （以下略）

なるほどー。これを使えば、電子申請システムのこれまでの様々な問題（脆弱性対応の問題と、指定されたバージョンがばらばらで複数の官公庁が共存できない問題）が一挙に解決できるのではないだろうか。

とはいえ、「Yes」ボタンだとか、やや不安の残るところがある。

というわけで、早速試してみた。

まず、JRE 5.0 Update 12をインストールする。この状態で、次のアプレットを貼り付けたHTMLを表示すると、図2のようになった。

<OBJECT
     classid="clsid:CAFEEFAC-0014-0002-FFFF-ABCDEFFEDCBA"
     width="600" height="200">
     <PARAM name="code" value="Test">
</OBJECT>

図2: JRE 5.0 Update 12のみインストールの状態で JRE 1.4.2系列の使用を指定した場合

ここで「ダウンロード」ボタンを押すと、JRE 1.4.2 系列最新版のダウンロードのページがInternet Explorerの別ウィンドウで開いた。

次に、ここで JRE 1.4.2系列最新版をインストールせず、JRE 5.0 Update 12も削除せず、ここに加えて、JRE 1.4.2_10 という古い脆弱なバージョンをインストールして、同じページを表示してみたところ、図3のようになった。*10

図3: JRE 5.0 Update 12 と JRE 1.4.2_10 がインストールされた状態で JRE 1.4.2系列の使用を指定した場合

このWebページのJavaアプレットを実行するには、Java Runtime Environment (JRE) 1.4.2 が必要です。JRE 1.4.2 はインストールされていますが、最新のリリースではありません。古いリリースを使用すると、セキュリティーの問題が発生することがあります。このアプレットを実行しますか？

[はい] [いいえ]

最新のリリースのJRE 1.4.2をダウンロードするとセキュリティが向上し、このダイアログが今後表示されなくなります。

JREのダウンロード

「はい」を押すと、実行が始まる。*11

書かれている文章は、まあまあ理解可能な内容だろうか。しかし、最新版のダウンロードを勧める文の文字が、日本語版では、小さくなりすぎて潰れている。原寸大では図4の通りだ。

図4: JRE 5.0 Update 12 における文字が小さすぎる様子（原寸大）

次に、ここで、JRE全体の最新版である JRE 6 Update 2 （最近は「JRE 6u2」とか言うらしい）を追加インストールして、同じページを表示してみたところ、図3とほぼ同一の画面が出た。このUIは JRE 6 Update 2 が出しているものであるはずだが、文字が小さい問題は改善されていないようだ。ここはぜひ日本語の読めるサンの人に改善してもらいたい。（社員もこのダイアログを見てないんでは？）

さて、ここで注意したいのは、JRE 5.0系列（のUpdate 7以降）や JRE 6.0系列がインストールされておらず、JRE 1.4.2 の古い脆弱なバージョンだけがインストールされた状態（いくつかの官公庁が現在もその状態を推奨している）では、このような機構は働かず、そのまま脆弱なバージョンが動いてしまうという点だ。

というわけで利用者側の使い方は次のようになる。

まず全員がすることとして、JRE 5.0 または JRE 6 の最新版をインストールしておく。そして既存の古いシステムを使う際に必要があれば、古いバージョン（脆弱性のある）のJREをインストールしてもよい。そのシステムを使う際、図3の警告が現れるので、サイトが本物サイトに間違いなく、信用できるならば「はい」ボタンを押して利用する。

ただし、その古いJREに見つかっている脆弱性が、上に書いた sandbox破れの脆弱性だけである場合ならば、それでよいだろう。しかし、画像処理のバッファオーバーフローとか、暗号ライブラリの脆弱性が見つかって修正されている（そしてそのシステムに影響がある脆弱性である）場合には、この方法で使用することは危険性が回避されないという問題は残る。

そして、利用者は古いバージョンのJREを消さなくてもよい。また、いつでも新しいバージョンのJREをインストールしてよい。

というわけで、「Java Update」が常に JRE 6 の最新版を勧めてくるというのは、このような機構を備えた JRE 5.0 Update 7 以降においては妥当な設計だったということになる。したがって、一昨日の日記に書いた「Sun Microsystemsの愚行」は、既に解決されていたということで、取り消す。

電子申請システムを安全かつ便利にするため今なすべきこと

上記の仕組みを使えば、JREを使わせる電子申請システムにこれまで指摘されてきた、脆弱性対応の問題と、複数の官公庁を1台で使えない問題が、同時に解決できると思われる。ただし、そのためには、サーバ側のHTMLを書き換える必要がある。といっても、アプレットを埋め込んだページのタグを上記引用部にある形式に書き換えるだけなので、すぐに対応できるだろう。

あとは、利用者にいかに的確に利用方法を説明するかだ。これまで告知されてきたことと異なるので、説明が下手だと混乱を招きかねない。

また、Javaアプレットの問題はこの方法で解決するにしても、JREとは別に独自ソフトをインストールさせている官公庁の場合、そのソフト（あるいはインストーラ）が、系列JREの任意リリースに対応できていない場合には、依然として問題が残る。

だが、本来、元々それは技術的にどうとでも解決できるはずのことであって、これまでバージョン決め打ちの出鱈目な開発が行われまくっててきたのは、受注ベンダーがクルクルパーか、役所がナメ切られているんだろう。決め打ちの出鱈目な開発事例は、今後、事例を列挙しながら、どんだけアホなんだよということを示すとともに、普通はどうやって作るのかを示すことで解決可能だということを示し、ベンダーにカモにされない調達仕様の書き方を検討していきたい。

というわけで、以下、アプレットの部分に関してだけ、各官公庁は何をすべきなのかをまとめる。

まず、各官公庁の各種電子申請、入札等のシステムの現状を分類する。上から順に理想的な取り組みをしているところと言える。

1. 動作環境として「JRE 5.0以上」を指定しており、実際のところ、JRE 6 でも問題なく動作しているところ （e-Gov が該当する？）
2. 動作環境として「JRE 5.0」を指定しているが、JRE 6での動作が不確かなため JRE 6では動かさないで欲しいと思っているところ （e-Gov が該当する？）
3. 動作環境として「JRE 1.4.2 系列の任意のアップデートリリース」を指定しているところ
4. 動作環境として「JRE 1.4.2_10 のみ」などと固定的にアップデートリリースのバージョンまで指定しているが、バージョンチェックコードを削除すれば、アップデートリリースのバージョンが新しくなってもそのまま動作すると予想されるところ （現在の厚生労働省電子申請システム等）
5. 動作環境として「JRE 1.4.2_10 のみ」などと固定的にアップデートリリースのバージョンまで指定しており、バージョンが新しくなってもそのまま動作するように改造するには相当のコストがかかりそうなためやりたくないと考えているところ （裁判所オンライン申し立システム等？）

これらのそれぞれは、Javaプログラムについて次の改良を施す。

1. 何もしない。そのままでよい。
2. 何もしない。そのままでよい。
3. 何もしない。そのままでよい。
4. バージョンチェックコードを削除する改良を施す。
5. バージョンが新しくなっても動作するよう改造するべきだが無理ならしょうがない。

そしてそれぞれは、次のように、サーバ側のHTMLを書き換える改善をする。

1. 何もしない。従来通りのバージョンを指定しないHTMLのままとする。
2. classid="clsid:CAFEEFAC-0015-0000-FFFF-ABCDEFFEDCBA" を指定するよう書き換える。
3. classid="clsid:CAFEEFAC-0014-0002-FFFF-ABCDEFFEDCBA" を指定するよう書き換える。
4. classid="clsid:CAFEEFAC-0014-0002-FFFF-ABCDEFFEDCBA" を指定するよう書き換える。
5. classid="clsid:CAFEEFAC-0014-0002-FFFF-ABCDEFFEDCBA" を指定するよう書き換える。

そして、それぞれは、利用者側で行う事前準備の手順として、次を指示するよう説明する。

1. • JREの最新版（現時点ではJRE 6系列）を導入してください。
   • 今後、Java Updateが新バージョンのリリースを告げてきたらそれを導入してください。
   • 他のシステムで必要とされている他のJREバージョンを追加で導入してもかまいません。

2. • JRE 5.0系列の最新版を導入してください。
   • 加えてJREの最新版（現時点ではJRE 6系列）を導入してもかまいません。
   • 今後、Java Updateが新バージョンのリリースを告げてきたらそれ（現時点ではJRE 6系列）を導入してください。
   • JRE 5.0は削除しないでください。
   • 他のシステムで必要とされている他のJREバージョンを追加で導入してもかまいません。
   • 今後、図3の画面が現れることがありますが、そのときは「はい」を押さず、「Javaのダウンロード」のリンクをクリックして、JRE 5.0系列の最新アップデートリリースを導入してください。

3. • JREの最新版（現時点ではJRE 6系列）を導入してください。
   • 加えて、JRE 1.4.2系列の最新版も導入してください。
   • 今後、Java Updateが新バージョンのリリースを告げてきたらそれを導入してください。
   • JRE 1.4.2は削除しないでください。
   • 他のシステムで必要とされている他のJREバージョンを追加で導入してもかまいません。
   • 今後、図3の画面が現れることがありますが、そのときは「はい」を押さず、「Javaのダウンロード」のリンクをクリックして、JRE 1.4.2系列の最新アップデートリリースを導入してください。

4. （同上）

5. • JREの最新版（現時点ではJRE 6系列）を導入してください。
   • 加えて、JRE 1.4.2_10 （最後が _10 のバージョンである必要があります）も導入してください。
   • JRE 1.4.2系列の _10 より新しいバージョンは導入しないでください。導入すると本システムは動作しなくなります。
   • 本システムを使用する際には図3の警告が毎回現れます。「Javaのダウンロード」を選択せず、「はい」ボタンを押してください。本システム以外のサイトで図3の警告が現れる場合がありますが、その際には「はい」を押すと危険かもしれません、そのサイトが信用できるかに注意してください。
   • 今後、Java Updateが新バージョンのリリースを告げてきたらそれを導入してください。
   • JRE 1.4.2_10 は削除しないでください。
   • 他のシステムがJRE 5.0系列の導入を必要としている場合はそれを導入してもかまいません。
   • 他のシステムがJRE 1.4.2系列の _10 以外のバージョンの導入を必要としている場合は、それを導入しないでください。導入すると本システムは動作しなくなります。他のシステムの利用を諦めるか、本システムの利用を諦めてください。

この対策を実施するにあたっては、全官公庁の全システムで一斉に実施した方がよい*12。なぜなら、いずれのケースでも JRE 5.0 か 6 をインストールすることを前提としているので、JRE 1.4.2系列を使用させているシステムのうちHTMLの書き換えに未対応のところや、1.3.1系列を使用させているシステムが、軒並み動かなくなる可能性がある（バージョンチェックで止めている作りのところは確実に止まる）からだ。

なお、Sunの文書には「Internet Explorer用Java Plug-in」の場合とされている。Firefoxの場合や、MacOSのSafariの場合はどうなるんだろうか？ という疑問は残る。IE限定にしてでも、この措置をとる価値はあるのではないか。

それから、Sunの文書にはこの機能が「暫定的な解決策」と書かれている点も気がかりだ。将来廃止になるということはたぶんないとは思うが。Sunとしては、Java Web Startに乗り換えることを推奨しているようだ。電子申請のシステムでも、本当にアプレットを使う必要があるのか考え直した方がよいのではないか。Webからのパラメタ付きリンクで起動（ファイルを指定してとか）したいためにアプレットにしているのなら、Java Web Startで同じことができるだろう。

■ 追記（11日）

「暫定的な解決策」については、上で省略した部分に書かれていた。（ここでも勝手に日本語訳しておく。無保証。）

• Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer, Java SE 6 Release Notes, Sun Microsystems
  Internet Explorer用Java Plug-inにおける、JREのファミリバージョンを指定したJavaアプレットの配備

  Sun Support Policy
  Sunサポート方針

  The family CLSID feature is only an interim solution supported by Sun for customers who have Java applets in transition. This solution enables customers to continue their existing deployment with the latest version of JRE in a specific family before the Java applets can fully be migrated to the latest JRE version in the latest family. Support for this feature will continue at least until Java Standard Edition 7 (Java SE 7) is released. Sun will not withdraw support for family CLSID without introducing new functionality addressing these customer needs. The family CLSID in the Java 2 Platform, Standard Edition 5.0 (J2SE 5.0) release supports JRE family versions 5.0 and 1.4.2. The family CLSID in the Java SE 6 release supports JRE family versions 6, 5.0, and 1.4.2. If you have deployment scenarios that cannot be satisfied by using the family CLSID feature, or you have an older product family, contact Sun Engineering Services for further assistance.

  ファミリCLSID機能は、過渡期のJavaアプレットをお持ちのお客さまのためにSunがサポートする暫定的な解決策にすぎません。この解決策は、Javaアプレットが最新のファミリの最新JREバージョンに完全に移行できるまでの間、特定のファミリの最新バージョンのJREで、お客さまの既存の配備を継続できるようにするものです。この機能のサポートは、少なくともJava Standard Edition 7 (Java SE 7) がリリースされるまでは継続します。Sunは、これらのお客さまニーズを扱う新たな機能を導入することなしに、ファミリCLSIDのサポートを撤回することはしません。Java 2プラットフォーム Standard Edition 5.0 (J2SE 5.0) リリースにおけるファミリCLSIDは、JREファミリバージョン 5.0 と 1.4.2 をサポートします。Java SE 6 リリースのファミリCLSIDは、JREファミリバージョン 6 と 5.0 と 1.4.2 をサポートします。もし、お客様が、ファミリCLSIDを使うことではご満足いただけないような配備シナリオをお持ちの場合、あるいは、より古い製品ファミリをお持ちの場合、さらなるお力添えがご入用でしたらSun Engineering Servicesまでご連絡ください。

それから、JavaアプレットおよびJNLPアプリケーション、standaloneアプリケーションそれぞれでの、使用バージョンの考え方が以下の文書にまとめられている。

• Java SE 6: New Deployment Policies for Java SE Customers, Sun Microsystems

  Recommendations for Developers
  開発者の皆さまへご忠告

この方針に従えという調達仕様とか、書けないものかねえ。

■ 追記（14日）

上で「Firefoxの場合や、MacOSのSafariの場合はどうなるんだろうか？」と書いた件、調べてみた。

Windowsで、JRE 6.0 Update 2 と JRE 1.4.2_10 がインストールされた状態で、以下のHTMLのページを、Internet Explorer 6.0 SP2 と、Firefox 2.0.0.4、Opera 9.21、Windows版Safari 3.0.2で表示したときの結果は次の表1のようになった。

<OBJECT
    classid="clsid:CAFEEFAC-0014-0002-FFFF-ABCDEFFEDCBA"
    width="600" height="200">
    <PARAM name="code" value="Test">
</OBJECT>
<EMBED
    type="application/x-java-applet;jpi-version=1.4.2_10"
    width="600" height="200" code="Test">
</EMBED>
<APPLET
    width="600" height="200" code="Test">
</APPLET>

なお、EMBEDにおいて、「jpi-version=」を「1.4.2」のようにファミリバージョンで指定しても、同様の結果となった。

次に、JRE 1.4.2_15 （この時点でセキュリティベースラインに等しいリリース）を加えてインストールした状態で、上記HTMLのEMBEDのところの「1.4.2_10」を「1.4.2_15」に変更して試したところ、表2のようになった。

つまり、JRE 5.0 Update 7以降がインストールされている前提において、次のことが言えそうだ。

• 脆弱なバージョンのJREもインストールしていても、タグがどのように書かれてもそれが勝手に起動することはない。
• ファミリバージョンを指定して脆弱な古いバージョンで（ユーザの確認付きで）起動することは、Internet Explorerでしかできない。
• ファミリバージョンを指定した起動は、（ファミリで最新のJREがインストールされていても）Internet Explorerでしかできない。

したがって、古いJREが残っていると危険という問題は、JRE 5.0 Update 7以降やJRE 6のインストールによって解消するが、要求するバージョンが異なる複数の官公庁の電子申請システムを1台で利用できるようにするには、Internet Explorerの利用を前提とするしかない（古いファミリのJREを要求する官公庁の利用において）。

OS での Safari の挙動はまだ確認していない。

なお、タグの書き方を説明したJDKの文書が以下にある。

• Java Plug-in での OBJECT、EMBED、および APPLET タグの使用, Java Plug-in 5.0 開発者ガイド

以下によると、「JRE 1.4.2_15」の「_15」の部分は（Sunの公式な見解として）「パッチバージョン番号」と呼ぶのだそうだ。このことからしても、日本の官公庁がいまだにこのバージョンを固定した開発を発注していることの異常さが確認できる。

• 付録 6:Sun のサポートする Specification-Version および Implemenation-Version の形式, Java Plug-in 5.0 開発者ガイド

  Specification-Version と Implementation-Version は、以下に示す Sun 製品の規則に従っています。また、サードパーティの製品は、拡張機能が最新かどうかを判断するために、Java Plug-in と同じ規則に従う必要があります。

  Specification-Version 文字列は、以下の形式をとります。

      n1.n2[.n3]

  n1、n2、n3 には整数が入り、n1.n2 は「メジャーバージョン番号」、オプションの n3 は「マイナーバージョン番号」 (「保守バージョン番号」とも呼ばれる) を表します。

  Implementation-Version も最初の部分は同じ形式ですが、以下の部分が異なっています。

  • 下線 (_) に続けて n4n5 を追加して、「パッチバージョン番号」 (「更新バージョン番号」とも呼ばれる) を表します。
  • または、ハイフン (-) を付けてマイルストン名 (ea、alpha、beta、rc ...) を追加します。これには後ろに整数の番号を付けることもあります (ea1、beta2、rc1 ...)。

  パッチバージョン番号とマイルストン名の両方を、Implemenation-Version 文字列で同時に使用することはできません。

  一般的な形式は以下のとおりです。

      n1.n2[.n3][_<patch_number>|-<milestone_name>]