最新 追記

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 2077   昨日: 2734

2007年07月01日

アドレスバー百景 その1

PCの世界ではWebブラウザにアドレスバーが必須なのが常識となっているが、ガラパゴス携帯にはアドレスバーがない。では、その他のモバイル機器やゲーム機らはどうなっているだろうか。

まず、Windows Mobile機のInternet Explorerを調べた。

写真
図1: Windows MobileのInternet Explorer

邪魔なくらい大きな領域をとってアドレスバーが表示されている。さすが、Microsoftが作っているだけのことあって、インターネットのセキュリティが当然に理解されている。

次に、Windows Mobile用のOperaブラウザ。

写真
写真
図2: Windows MobileのOperaブラウザ(上:通常、下:全画面表示モード)

やはり、アドレスバーは当然に出ている。全画面表示にしても、アドレスバーだけは現れるようになっている。さすが、インターネットの技術を牽引する力のある世界的企業は当然にこうだ。

では次に、ソニー・コンピュータエンタテインメント(SCEI)のPSPはどうだろう?

写真
写真
図3: PSPのWebブラウザ(上:△ボタンを押す前、下:△ボタンを押した後)

閲覧状態ではアドレスバーがない。しかし、「△」ボタンを押すと「にゅる」っとしたアニメーションとともに、上からアドレスバー、下からメニューバーが現れるようになっている。もう一回「△」ボタンを押すと元に戻る。同じボタンを2回押すだけで確認ができるのは、まあよい。

しかし、この方法はちょっと微妙だ。もし偽サイトが、この挙動をアニメーション表示するGIF画像を貼り付けていたらどうだろう? 違和感なく再現するのは無理? ボタンを押さないで出てしまうから違和感を感じて騙されない?

PSPはFlashをサポートしている。偽サイトがこの挙動をエミュレートするFlashを仕掛けていたら? 「△」ボタン押下時のアクションをFlashで記述できないようになっている? だから大丈夫?

微妙だ。やはり、アドレスバーはWebページ画面の枠の外に設置するべきではないか? PSPは画面はそれほど狭くないのだから、アドレスバー領域を設けるくらい十分に妥当だと思うのだが。

次に、ソニーのmyloの場合。

写真
図4: myloのブラウザ

アドレスバーはない。Operaで作られているはずなのに、これはいったいどうしたことか。アドレスバーを設けなかった責任は、Opera社ではなくカスタマイズしているソニーにある?

今見ているページのURLを確認するには、図5のように、「Option」ボタンを押して、下キーを8回押して「アドレスの編集」を選び、実行ボタンを押して、アドレスを表示させたうえ、「Back」ボタンを押して戻るというかなり面倒な手順になる。(Flashはサポートされていないので、この挙動をエミュレートすることはできないだろう。)

写真 写真
図5: myloでアドレスを確認する手順

画面が狭いからというのはわかるが、下から2段目にタブ領域を設けているのだから、タイトル表示と共に、URLも表示したらどうか。URLは長くなりすぎるので、ドメイン名だけでも表示してはどうか。*1

今回のまとめ:

ブラウザ 構造 必要ボタン押下数
Windows Mobile用IE 0
Windows Mobile用Opera 0
PSP 2
mylo × 11

その他、調べてみるべきデバイスは何があるだろう?

  • Wii (まだ所有していないので確認できていない)
  • PLAYSTATION 3 (まだ所有していないので確認できていない)
  • acTVila対応テレビ (買う予定がなく確認できていない)
  • ……。

誰か調べてくれないだろうか。

ちなみに、iPhineはちゃんとアドレスバーがあるようだ。世界に通用するApple Computerなので当然だ。

*1 その際、<TITLE>要素にドメイン名を書いて騙そうとしてくる攻撃に耐え得るようなデザインが必要だが。また、長すぎるドメイン名による攻撃にも騙されないような表示方法の工夫も必要。

本日のリンク元 TrackBacks(100)

2007年07月07日

Refererを誤送信するブラウザが最近も存在する

この日記の「リンク元」を見ていると、明らかにここへのリンクなどあるはずのないサイトからのRefererが送られてくることがしばしばあるのに気づく。こうしたリンク先でないところへのReferer送出は、古くは、Internet Explorer 4.0, 4.01, 5.0, 5.01のバグとして知られる。Internet Explorer 5.5以降でこのバグは解消された。さすがにもう、IE 5.01以前を使っている人はいないだろう。

その後、auの携帯電話に搭載のブラウザにこのバグが見つかって修正されたことが何度かある。(JVNでは、「脆弱性」に該当しないが「ユーザへの周知を目的としてこの問題を掲載」という扱い*1のようだ。)

  • JVN#15243167 携帯電話の Web ブラウザにおける referer ヘッダの扱いに関する問題, JVN, 2005年12月9日

    携帯電話によるインターネット接続サービスのブラウザとして使われている Openwave Systems 社の製品には、ある特定の状況において、referer 情報の送信機能に不具合があることが確認されています。

    この問題は KDDI 株式会社の携帯電話サービスである au の端末について報告されました。KDDI 株式会社では、RFC2616 記載の仕様に反する挙動を示す不具合であるとして、対策情報が公開されています。JVN では製品開発者との調整のうえ、ユーザへの周知を目的として、この問題を掲載しています。

  • auの携帯電話にReferer誤送出の欠陥、KDDIは回収せず, スラッシュドットジャパン, 2002年7月28日

    ZDNetの記事*2によると、このバグのある機種は、A3012CA、A3011SA、A3013T、 C5001T、C3001H、C3003Pの6機種。KDDIは、8月中旬以降にauショップでのバージョンアップで対応するとしているが、ダイレクトメールなどでの告知は予定していないと伝えている。

では、最近観測されるRefererはどのブラウザのものか。アクセスログから少し調べてみたところ、次の記録があった。

------------.ap.plala.or.jp - - [03/Jun/2007:04:58:11 +0900] "GET /diary/20070521.html HTTP/1.1" 200 20164 "http://www.asahi.com/culture/nikkan/index.html" "Mozilla/5.0 (compatible; PEAR HTTP_Request class; http://www.rcdtokyo.com/pc2m/)"
------------.ap.plala.or.jp - - [03/Jun/2007:05:35:21 +0900] "GET /diary/20070601.html HTTP/1.1" 200 29500 "http://sportsnavi.yahoo.co.jp/rugby/index.html" "Mozilla/5.0 (compatible; PEAR HTTP_Request class; http://www.rcdtokyo.com/pc2m/)"

------.dc01.axelmark.net - - [09/Jun/2007:01:04:39 +0900] "GET /diary/20070601.html HTTP/1.1" 200 97639 "http://business.nikkeibp.co.jp/article/life/20070522/125376/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; mobazilla)"
------.dc01.axelmark.net - - [09/Jun/2007:23:53:50 +0900] "GET /diary/200407.html HTTP/1.1" 200 130024 "http://www.edy.jp/error/not_found.html" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; mobazilla)"

pc2m」と「mobazilla」というブラウザにこの問題があるようだ。再現手順はわからない。

栃木県警の無断リンク禁止規定の復活はシステム不具合による事故

5月に「 栃木県警サイトのリンクポリシーが後退?」という話があった。

2006年9月の時点で、

リンクについて
当サイトへリンクされる場合は、リンク元のサイトの運営主体、リンクの目的及びリンク元のページの URLを事前にご連絡ください。無断リンクは禁止とします。

と書かれてたものが、2006年10月の時点では、

リンクにつきましては、営利を目的とせず、公序良俗に反しない限り基本的に自由ですが、リンクを希望される方は、ホームページ上のご意見ご要望メールでご連絡ください。

と改訂されていたのだが、2007年5月の時点で、

リンクについて
当サイトへリンクされる場合は、リンク元のサイトの運営主体、リンクの目的及びリンク元のページの URLを事前にご連絡ください。無断リンクは禁止とします。

と過去の内容に戻っていたわけだ。

それが、6月に訪れてみたところ、

リンクにつきましては、営利を目的とせず、公序良俗に反しない限り基本的に自由ですが、リンクを希望される方は、ホームページ上のご意見ご要望メールでご連絡ください。

と改められていた。

このことについて栃木県警に問い合わせていたところ広報相談課よりお返事があり、「2007年5月頃、更新におけるシステムの不具合により、変更前の記載に戻ってしまうという事案が発生」し、「不具合を認知、把握した時点で、ただちに「基本的に自由である」旨の記載に戻し、再度更新を行った」ものとのことだった。

*1 「ソフトウエア等の脆弱性関連情報に関する届出状況 [2005年第4四半期(10月〜12月)]」のp.9に次のようにある。

≪「携帯電話のWeb ブラウザにおけるReferer ヘッダの扱いに関する問題≫(項番14)は、製品開発者により脆弱性ではないとされていますが、ユーザへの周知を目的として、対策情報をJVN へ公開しました。

*2 現ITmediaの記事。

本日のリンク元 TrackBacks(100)

2007年07月08日

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

目次

  • 今回の報道
  • 過去の経緯
  • 何が問題なのか
  • 本当に動かなくなるのか
  • 内閣官房に期待すること
  • 新たな問題(Sun Microsystemsの愚行)

今回の報道

先週、NHKが、厚生労働省の電子申請システムのセキュリティ上の問題点を取り上げていた。

  • NHKニュース「厚労省 欠陥ソフトを放置」, 2007年7月5日 ニュース7

    厚生労働省はホームページ上で特定のコンピューターソフトを提供していますが、このソフトには重大な欠陥があり、利用者がパソコンの情報を盗まれるおそれのあることがわかりました。(略)

    厚生労働省は、こうした情報を把握できず、5か月以上にわたって、欠陥が修正された最新のソフトに切り替えたり、利用者に注意を呼びかけたりするなどの対策をとっていませんでした。

  • NHKニュース「厚労省 欠陥ソフト提供中止」, 2007年7月6日 おはよう日本

    厚生労働省は6日未明になって安全性が確保できないとしてソフトの提供を中止する措置をとりました。また、ホームページに注意を呼びかけるコメントを載せるとともに、ソフトを削除する手順などもあわせて掲載しました。

  • NHKニュース「欠陥ソフト問題 厚労相が謝罪」, 2007年7月6日 正午のニュース

    これについて柳沢厚生労働大臣は、閣議のあとの記者会見で、「去年12月にソフトのメーカーがみずから欠陥について情報を出したというところからいくばくもなく、アクションを取られるべきであった。少なくとも内閣府から連絡を受けた6月26日の段階で、即日、同じことをホームページ上で明らかにすべきだった」と述べました。そのうえで、「そういった手続きの遅れについてほんとうにおわび申し上げます。今後は、緊張感を持って反省の上に立ってしっかりとやっていきたい」と述べました。

  • NHKニュース「欠陥ソフト 厚労省が改修作業」, 2007年7月7日 おはよう日本

    厚生労働省はソフトの提供を中止し、対策を検討していました。その結果、提供するソフトを欠陥のない最新のものに入れ替えることを決め、7日未明からシステムを停止させて改修作業を進めています。改修されたシステムの運用は、7日午前9時から始める予定です。

  • NHKニュース「欠陥ソフト 省庁の実態調査へ」, 2007年7月7日 正午のニュース

    厚生労働省が重大な欠陥の見つかったコンピューターソフトを5か月以上にわたってインターネット上で提供していた問題で、省庁の情報セキュリティー対策に取り組んでいる内閣官房情報セキュリティセンターは、ほかの省庁でも欠陥のあるソフトを提供しているおそれがあるとして、すべての省庁のソフトの利用の実態を調べることになりました。(略)

    内閣官房情報セキュリティセンターの伊藤毅志参事官は「本来は省庁それぞれが自主的に取り組むべきだが、調査を行い、各省庁にあらためて対策を促すことが必要と判断した」と話しています。

この件では私も5日のニュースでコメントをした(勤務先に取材があったため)わけだが、この話題はもう5年も前から繰り返し繰り返し言われてきたことで、「いまさらその話題を?」と思った。実際、正直飽き飽きしていたので、ここしばらく各省庁の電子申請システムを見てまわることをしておらず、厚生労働省にこの問題があることは把握していなかった。

他の報道を見てみるに、どうやら今回の新しさは、NISC(内閣官房情報セキュリティセンター)の勧告を無視したという点にあるようだ。

  • 厚労省の電子申請欠陥、10日間放置…個人情報流出の恐れ, 読売新聞, 2007年7月5日

    ソフト会社は昨年12月の時点で欠陥を公表していたが、同省は気づいていなかった。

    同省は先月26日、内閣官房情報セキュリティセンターからの指摘で初めて問題を認識したが、利用者に注意喚起せず、システムを稼働させていた。

  • 厚労省のソフトに欠陥 利用者情報流出のおそれ, 朝日新聞, 2007年7月6日

    昨年度のシステムの利用件数は約9万5000件。(略)

    ソフト開発会社は昨年12月以降、自社のホームページ(HP)上で注意喚起したが、同省は内閣官房から連絡を受ける6月26日まで欠陥を把握できず、その後も「利用者に迷惑をかける」との理由で利用中止や注意喚起などをしていなかった。

  • 厚労省の電子申請、欠陥ソフトを放置・情報流出の恐れ, 日経新聞, 2007年7月6日

    同省は6月下旬に内閣官房情報セキュリティセンターから指摘を受けたが、利用者に注意喚起しないまま放置していた。

  • 厚労省の電子申請ソフト欠陥、原因はパッチ更新の慢性的な滞り, 日経IT Pro, 2007年7月6日

    サン・マイクロシステムズは昨年の12月と今年5月の2度に渡ってパッチを公開していたが、厚労省はこのときも更新していなかった。6月にはサン・マイクロシステムズが、今回の問題の原因となった新たな脆弱性が見つかったと発表している。それを受けて6月26日に内閣官房情報セキュリティセンターがJREを導入している各省庁に注意を促した。しかし、厚労省では対策を講じず欠陥のあるソフトがそのままダウンロードできる状態だった。

    7月2日には内閣官房情報セキュリティセンターが各省庁に対してサン・マイクロシステムズからパッチが出たことを通告。それでも厚労省は7月5日まで対応をとっていない状態だったという。

  • 厚労省、欠陥ソフト放置 公表後5カ月 年金申請など利用, 東京新聞, 2007年7月6日

    厚労省HPでは、今年一月から五月までに約四万二千件の利用があった。利用者のパソコンが外部から操作され、入力した情報を盗まれる恐れがあることが分かり、開発会社が今年一月に事実を公表、欠陥を改善したソフトを公開した。他省庁はこれに更新していたが、厚労省は先月二十六日まで気付かず、それ以降も対応していなかったという。

これが見過ごされなかったもうひとつの要因は、システムがちゃんと利用されていて、利用者がけっこう多いということなのだろう。たとえば、最高裁判所のオンライン申立てシステムは、最低最悪の糞野郎なのだが*1、正直、誰も利用していない(札幌地裁しか受け付けていない)のでもう放置でもいいやという諦めムードだったのに比べると、厚生労働省のシステムは昨年度に9万5千件、今年も既に4万2千件もの利用があるというのだから、無視できない問題と言えるのだろう。

過去の経緯

ここで過去の経緯を振り返っておこう。2002年3月末に最初の電子申請システムが総務省と経済産業省と国土交通省で始まった。このとき、CD-ROMで専用ソフトが配布されたのだが、同梱されたJREがその時点で脆弱性の知られたバージョンであったため、次の展開となった。

  • 経済産業省の電子申請ソフトに問題発覚, 日経IT Pro, 2002年4月8日

    ITEM2000は、本体の「ITEM2000」のバージョン1.02と、Javaの実行環境「Java 2 Runtime Environment」(JRE)のバージョン 1.3.1_01の2種類のソフトで構成されている。問題はJREの方にあった。(略)

    既にこのJREの問題について、米サン・マイクロシステムズ社は3月18日に同社のWebページで告知していた。しかし、経済産業省とITEM2000の開発元であるニューメディア開発協会は、この告知に気付かなかった。両者がこの問題に気付いたのは4月4日の夕方で、しかも産業技術総合研究所の研究員の指摘で分かった。

これにより各省庁は注意喚起を出すようになったのだが、時が経つにつれ、内容を理解しないで見よう見まねで注意喚起文を書くところが現れるようになり、誤った告知がされるようになっていった。

また、JREが自動アップデート機能を搭載するようになると、自動アップデートを止めるよう指示するところが現れるようになっていった。

昨年には、そもそも脆弱性以前の問題として、指定されているバージョンが異なるために複数の省庁を1台のパソコンで使えないという不満も利用者の間から顕になってきていた。

  • 電子政府、縦割り弊害 同一パソコンで申請不可, 朝日新聞, 2006年3月26日

    インターネットによる国への電子申請で、一つの申請ができるようにパソコンを設定すると、同じパソコンからは別の省庁などに申請できなくなる不具合があることがわかった。多くの省庁がシステムを発注する際、ソフトのバージョンアップへの対応を考慮していなかったことが背景にあるという。不具合解消を目指し、総務省は4月3日、電子政府のホームページ(http://www.e-Gov.go.jp/)に総合受付コーナーを設ける。

    (略)日本行政書士会連合会などによると、昨年末から東京や大阪などで始まった新車のオンライン登録ができるように設定したパソコンからは、不動産・商業登記の申請や国交省の電子入札の利用者登録ができない。

    また、多くの申請では個人認証が必要だが、公的個人認証カードが有効であるかどうかを確認するシステムを使用するパソコンでは、不動産登記ができない。

  • 電子政府が使えない理由、縦割りの弊害?JREの弊害?, スラッシュドットジャパン, 2006年3月26日

しかし、上の朝日新聞の記事にあるように、いくつかの省庁が、昨年度から e-Gov のサイトへ電子申請システムを移行させており、この問題は、e-Gov への一本化によって解決されていくのだろうと思っていた。(そのため関心を失っていた。)

何が問題なのか

今回の大々的な報道に対し、何が問題なのかわからないという声を耳にした。後から追従したCNET Japanの記事を見ても、注意喚起を行っていなかったことが問題であるかのように誤解している様子が見られるし、厚生労働省電子申請システムのヘルプデスクに電話すると、「サンの問題であるが(我々の問題ではないが)注意喚起することにした」というようなことを言う。

というわけで、何が問題なのかを改めてここに書こうと思った……のだが、調べてみると、言いたいことは2年前の日記に既に書いていた。

要点を抜き出しておく。

インストールさせる者による脆弱性告知

JREをインストールさせている官庁(中央省庁および地方自治体)にとって、 JREに脆弱性が見つかるたびに対応策を告知することは義務であるという考え方は、概ね普及したようである。(Acrobat Readerのインストールを要求している官庁も、Acrobatの脆弱性発覚時に告知するべきだと思うが、それは行われていない。)まことに適切なことである。しかし、告知には2種類のものがある。Javaのアップデートをしないで対処せよと呼びかけるものと、アップデートせよと呼びかけるものだ。

追いつかない対応

一方、現時点で脆弱なバージョンを使わせているにもかかわらず危険性を伝えていないところもあり、警察庁、防衛庁、外務省、厚生労働省などがあった。

このところ 1.4.2系列のJREに頻繁に脆弱性が発覚しており、各官庁の対応も追いつかない様子が見られる。しかし、そもそも「_XX」の「アップデートリリース」が出るたびに、「対応」が必要となること自体がおかしいのではないか。

たとえば、総務省の対応はスマートなものになっている。

5.Java実行環境

次に示すいずれかのJava実行環境が必須です。(注3)

・Microsoft社 Java Virtual Machine(以下、『MSJVM』)(注4)

・Sun Microsystems社 Java 2 Runtime Environment v1.3.1、v1.4.1、 v1.4.2(以下、『JRE』)(注5)

(注5) システムの動作確認はv1.3.1_10、v1.4.1_07、v1.4.2_03の各バージョンで行っています。セキュリティーの観点からは、最新バージョンの導入を推奨します。 JREはSun Microsystems社のページからダウンロードできます。

「_XX」のバージョンをとくに指定していない。つまり、「どのバージョンでも動きます」ということを言っていて、だからこそ、どのバージョンを使うかはユーザの責任だ(常に最新バージョンを使うことを推奨)と言えてしまっている。

総務省のアプレットは規模が小さくて、他省庁のアプレットは大きいといった事情の違いがあるのかもしれないが、本来目指すべきところは、このように実行系のバージョンに依存しないアプレット作りであろう。

それが簡単なことではないことは知っている。1.4.1 が 1.4.2 になると動かなくなるということはよくあることだ。だが、「_XX」という「アップデートリリース」で動かなくなるというのは、どういう作りをしているのか? JREのバージョンを上げると動かなくなるというのは、枯れていない最新ライブラリを使っている場合を除けば、やはり下手糞なプログラムの書き方をしている(誤ったライブラリの使い方をしているなど)からではないか。

「_XX」をセキュリティアップデートだと位置づけるのであれば、それによってアプリケーションが動かなくなるということは、ほとんど起きないものでなくてはならない。Windows Updateと同様にだ。

本当に動かなくなるのか

そもそも、電子申請のアプレットにおいて、「_XX」のバージョンを上げると動かなくなるという事態が、本当に起きているのだろうかという疑問がある。実際、「_XXにアップデートすると○○の機能が正常動作しなくなる現象が報告されています」といった注意を呼びかけている役所をこれまでに見たことがない*2。単に、「動作確認ができていません」というだけのことではないだろうか。なぜそこまで動作確認に拘るのか?

もしかするとこれは、まさにいわゆる役所仕事の弊害にすぎないのではないだろうか。つまり、発注時に、「JRE 1.4.2_04 での完動を保証すること」といった要件を無思慮に入れているために、こういうことになっているのではないか。新たなアップデートリリースが出ると、役所は「動作を保証できない」という思考に短絡し、正常に動くかもしれない可能性と脆弱性回避のトレードオフという発想に思考が及びもしない。そして、「アップデートを止める」という発想に陥るか、でなければ、新バージョンでの動作検証と動作保証のための改修という新たな開発事業を発注するということをやっているのではないか。

新たな「_XX」バージョンのリリースに対して、動作検証に何か月〜半年以上もかかっているというのがおかしい。予算を確保するところから始めているのではないか?

ここは、「JRE 1.4.2 の任意のアップデートリリースでの動作を保証すること」という発注要件にするべきだろう。もちろん、そのための費用を上乗せしてだ。

JRE 5.0で事態は改善されるか

経済産業省の場合は JRE 5.0(別名 JRE 1.5)へ移行したようだ。JRE 5.0では、「_XX」というバージョン表記は廃止され、「Update 4」といった名前が付けられるようになった。

これにより、これが「アップデートリリース」であることが名前からして明確となったわけで、もはや官庁が国民に対して、「Update 1での動作しか保証していません」だとか、「Update 2にしないでください」などと呼びかけることは許されなくなると期待できる。Windows XPで「Service Pack 2の適用をさせない」などということが許されないのと同様にだ。

経済産業省は、次のように、JRE 1.4.X_XX を捨てて、JRE 5.0 系を使うように指示している。(略)しかし、先ごろ発覚した Update 1の脆弱性については触れられていない。これは次のように考えることが可能かもしれない。 JRE 5.0では自動アップデートの機能が Windows Update同様に、タスクバーに現れるようになった(図1)。これによって、JREのアップデートはユーザの責任ということになったと言うことが可能かもしれない*3。

しかしそれでよいのだろうか? Windowsをインストールさせている(というか、インストールして販売している)パソコンメーカの何社かは、Windowsの脆弱性パッチがリリースされるたびに、そのパソコンのポータルサイト等で Windows Updateの適用をうながす告知をしているくらいなのだから、最初から入っているわけではないJREを自身の提供サービスの都合で消費者に入れさせる事業者および官庁は、JREの脆弱性情報を告知するべきではないだろうか。せめて政府機関くらいはそうしてほしい。Acrobat Readerの脆弱性についても

つまり、

  1. そもそもJREの「_XX」というバージョンが変わっても動くようにアプリケーションを作るべきであるところ、それをしていない省庁があり、
  2. そうなっていないならば、JREのセキュリティアップデートが出たら直ちにアプリケーションも対応バージョンにアップデートしなければならないところ、それをやっていない省庁があり、
  3. そのような場合には、直ちに回避策を利用者に周知する責任があるところ、それを怠る省庁があって、

今回は厚生労働省が上記 1. 2. 3. の全てに該当したところ、さらに内閣官房の勧告を無視して、大臣が陳謝する事態にまで至った。*2

2年前の日記では、発注者側が「1.4.2_04 での完動を保証すること」といった指定をしているのではないかという説を唱えたが、昨年のスラッシュドットジャパンのストーリでは、役所の方が業者にカモにされているのではないかと揶揄されていた。

Re:仕様書の書き方がわるいのか? (スコア:0)
Anonymous Coward のコメント: 2006年03月26日 18時31分 (#909216)

JREがバージョンアップしたら
また金蔓になるとか業者が思ってたりして。
「仕様変更は有料です。」とかね。

電子政府が使えない理由、縦割りの弊害?JREの弊害?

2005年の時点では、警察庁、防衛庁、外務省でも今回の厚生労働省と同様に何か月も放置していた状況があったわけだが、おそらく、上記 2. の対応をするには無視できない額の費用(テスト料金と、プログラム改修料金)が要求されていて、それが確保できないという状況があったのではないか。

しかし今回はどうか。5日夜に報道され、7日朝には新バージョンを提供したのだから、1日で対応できたわけだ。これはいったいどういうことか?

本当に動かなくなるのか

上記 1.の「「_XX」というバージョンが変わっても動くようにアプリケーションを作るべきであるところ」について、厚生労働省のシステムが本当にそうなっていないのかどうか、今回提供された改修バージョン(3.0.6)がどう変更されたのかを逆コンパイルして*3調べてみた。

「jp.go.mhlw.hanyou.apr.APRShinseiDataIchiran」というクラス(extends JFrame)があり、mainメソッドに次のコードがある。

    boolean result = checkJavaVersion();
    if (!result) {
        String param[] = errDialog.getDialogMessage("ErrAPR01-129-375");
        JOptionPane.showMessageDialog((Frame)null, param[1], param[0], 0);
        System.exit(1);
    }

「checkJavaVersion」メソッドは次のようになっている。

private static boolean checkJavaVersion() {
    ...
    String javaVersion = System.getProperty("java.version");
    boolean result = false;
    for (int i = 0; i < APRShinseiConst.JAVA_VERSION.length; i++) {
        String version = APRShinseiConst.JAVA_VERSION[i];
        ....
        if (!javaVersion.equals(version)) continue;
        result = true;
        break;
    }
    ...
    return result;
}

そして、5日まで配布されていた 3.0.5 と、7日から配布され始めた 3.0.6 を比較すると、「APRShinseiConst」クラスの以下の違いだけであった。(「, "1.4.2_15"」の12バイトが追加されただけ。)

3.0.5 のコード

public static final String JAVA_VERSION[] = {
    "1.3.1_06", "1.3.1_07", "1.3.1_08", "1.3.1_09", "1.3.1_10", "1.3.1_11", "1.4.1", "1.4.1_01", "1.4.1_02", "1.4.1_03", 
    "1.4.1_04", "1.4.1_05", "1.4.1_06", "1.4.1_07", "1.4.2", "1.4.2_01", "1.4.2_02", "1.4.2_03", "1.4.2_04", "1.4.2_05", 
    "1.4.2_06", "1.4.2_07", "1.4.2_08", "1.4.2_09", "1.4.2_10"
};

3.0.6 のコード

public static final String JAVA_VERSION[] = {
    "1.3.1_06", "1.3.1_07", "1.3.1_08", "1.3.1_09", "1.3.1_10", "1.3.1_11", "1.4.1", "1.4.1_01", "1.4.1_02", "1.4.1_03", 
    "1.4.1_04", "1.4.1_05", "1.4.1_06", "1.4.1_07", "1.4.2", "1.4.2_01", "1.4.2_02", "1.4.2_03", "1.4.2_04", "1.4.2_05", 
    "1.4.2_06", "1.4.2_07", "1.4.2_08", "1.4.2_09", "1.4.2_10", "1.4.2_15"
};

実際、このシステムを使おうとすると(JRE 1.4.2_15 の環境で 3.0.5のソフトウェアを起動すると)図1のダイアログウィンドウが出て、終了するようになっている。

画面キャプチャ
図1: 厚生労働省のソフトウェアを起動するとエラーが出て終了する様子

つまり、わざわざ動かないように作られているわけで、今後新たに JRE 1.4.2の「_16」がリリースされたとき、利用者がそれにアップデートすると、このチェックにかかってシステムは動かなくなるという事態が再び繰り返されるのは目に見えている。もし、この「checkJavaVersion()」を取り除いておいたなら、「_16」がリリースされてもそのまま動作するだろう。

1.5での動作が不安なのでバージョンチェックをするというのならまだ話はわかるが、それなら、「1.4.2_15」というバージョン文字列全体の一致ではなく、「1.4.2_」という先頭部分文字列の一致でバージョンを制限するようにしたらいい。

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

内閣官房に期待すること

2年前の日記に書いていたように、総務省や経済産業省は2年前の時点で、JREのアップデートリリースに依存しない形でプログラムを作っていた。現在の状況を確認してみると、一本化されつつある e-Gov のシステムでは、図2のように案内されており、1.4.2 または 5.0 というバージョン指定で、最新のリリースのものを使えばよいとされている。

画面キャプチャ
図2: 現在の e-Gov における「動作環境」の案内

次に示すいずれかのJava実行環境が必要です(最新のものを推奨)。

* Windows2000 SP4 および WindowsXP SP2
Sun Microsystems社 J2SE 1.4.2 Java Runtime Environment
Sun Microsystems社 J2SE 5.0 Java Runtime Environment

すべての省庁がこのような適切な案内をするべきところ、それができていないのは、省庁によって担当者のIT理解力が異なっているためではないだろうか。だからこそ、e-Gov に一本化して、IT理解力のある担当者をそこに集中させるという方策は正しい。

しかし、未だ e-Gov へ移行できない省庁があること、また、いくつかの省庁には部分的に e-Gov へ移行していないシステムもあるようであるし、地方公共団体のシステムは e-Gov に移行しないであろうから、単に e-Gov 一本化で万事解決する話でもないように思われる。

そうすると、IT理解力に斑があるのが現実である各官公庁の全部を正しく対処させるためには、どこかの機関が命令するなり、指導するなり、何らかの統括的な管理が不可欠であろう。

その点で、7日正午のNHKニュースにあった、NISC(内閣官房情報セキュリティセンター)が対応に乗り出すという話は良いニュースだと思う。

内閣官房情報セキュリティセンターは、ほかの省庁でも欠陥のあるソフトを提供しているおそれがあるとして、すべての省庁のソフトの利用の実態を調べることになりました。(略)

内閣官房情報セキュリティセンターの伊藤毅志参事官は「本来は省庁それぞれが自主的に取り組むべきだが、調査を行い、各省庁にあらためて対策を促すことが必要と判断した」と話しています。

NHKニュース「欠陥ソフト 省庁の実態調査へ」, 2007年7月7日 正午のニュース

実態を調べることはまずはの一歩だとして、さらに進めて、政府統一基準に盛り込むべきだ。NISCはこれまでに、「政府機関の情報セキュリティ対策のための統一基準」なるものを提供しており、この中に、「政府機関統一基準適用個別マニュアル群」というものがあり、そこに「ソフトウェア開発における情報セキュリティ対策実施規程 策定手引書」という文書がある。

こうした基準文書に、次のことを盛り込むべきである。


国民に導入させて使用させるソフトウェアを開発する際には、次の各要件を満たさなければならない。

  1. 当該ソフトウェア(以下甲とする)の動作環境として、サポート期限切れのソフトウェアの別途導入を利用者に求めてはならない。
  2. 甲の動作環境として他のソフトウェア(以下乙とする)の別途導入を利用者に求める場合には、前項の要件を満たすため、開発立案者は、甲の利用年限を計画し、以下の措置をとる。
    • 乙のサポート期限を確認(または予測)し、甲の利用年限より長いものであることを確認すること。
    • 乙のサポート期限が甲の利用年限より短い場合は、乙のサポートが終了する前に甲の更新バージョンを開発し提供するよう、計画すること。
    • 乙のメンテナンスリリースのバージョン更新(セキュリティアップデート等)の適用によって甲が動作しなくなる事態を、可能な限り排除すること。
    • 前項の要件を満たすため、乙のメンテナンスリリースのバージョン番号の判定によって故意に甲の動作を停止させることのないよう、甲の開発仕様書に明記すること。
  3. 前項の場合で、乙が自動アップデート機能を備えている場合、その機能を無効に設定するよう利用者に促すことをしてはならない。
  4. 同、乙が自動アップデート機能を備えていない場合、甲の配布者は、乙にセキュリティ脆弱性が発覚して修正バージョンがリリースされた際に、随時、乙のアップデートが必要である旨を利用者に告知しなければならない。

また、内閣官房は「すべての省庁のソフトの利用の実態を調べる」とのことだが、調査にあたっては次のことについて調べるのがよいと思う。

  1. 電子申請システムのために国民に導入を求めているソフトウェアの一覧
  2. 前項各ソフトウェアについて、導入すべきバージョンをどのように指定しているか
  3. そのバージョンはサポート期限切れのものでないか
  4. 前項が期限切れのものとなった際に利用者に回避策を告知するようにしているか
  5. 各ソフトウェアについて、最新バージョンを導入すると電子申請システムが動作しなくなるという事実が現在までに存在しているか
  6. 今後、最新バージョンの導入によって電子申請システムが動作しなくなる事態が発生した際に、どのように対応するかを計画しているか
  7. 各ソフトウェアは自動アップデート機能を備えているか
  8. 自動アップデート機能を備えているソフトウェアを導入させている場合、各ソフトウェアについて、自動アップデート機能を無効に設定するよう国民を促していないか
  9. 自動アップデート機能を備えていないソフトウェアを導入させている場合、脆弱性発覚時に利用者に注意喚起の告知を行っているか

7月5日の時点での厚生労働省の場合、回答例は以下のようになる。

  1. JRE
  2. JREについて 1.4.2_10 のバージョンを指定している
  3. 期限切れ
  4. 告知していない
  5. 動作しない事実がある
  6. 計画していない
  7. 備えている
  8. 無効にするよう促している
  9. 該当しない

7月8日の時点での厚生労働省の場合では、回答例は以下のようになる。

  1. JRE
  2. JREについて 1.4.2_15 のバージョンを指定している
  3. 現時点では期限切れではないが、いつ期限切れになるか不明であり、これまでの経緯からすれば半年前後が経過した後に期限切れとなる可能性が高い
  4. これまでは告知を怠っていたが、今後は告知していく予定
  5. 指定しているバージョンが最新版であるが、1.5を導入すると動作しなくなる事実がある
  6. 計画していない
  7. 備えている
  8. 無効にするよう促している
  9. 該当しない

理想的な対処をしているところの回答は以下のようになる。

  1. JRE
  2. JREについて 1.4.2 または 1.5 系列の任意のバージョンを指定している
  3. 1.5系列については、20XX年までは期限切れにならないと予測している
  4. 期限切れとなったことがない
  5. 現在のところそのような報告はない
  6. 計画している
  7. 備えている
  8. 促していない
  9. 該当しない

新たな問題(Sun Microsystemsの愚行)

この2年の間に、新しい不都合が生じるようになっていた。Sunはこの間にJRE 6.0をリリースしたのだが、その結果、Javaの自動アップデート機能は、JRE 5.0をインストールしている人に対しても、JRE 6.0のインストールを促すようになってしまった(図3)。

画面キャプチャ
図3: JRE 5.0最新版利用中に現れる「Java Update」の画面

これは喩えて言えば、Windows 2000 SP4 ユーザに Windows XP SP2 への自動アップデートを促すようなもの(XPが有料であるのは別として)で、そんなメジャーバージョンのアップデートをしてしまったら、それこそ何が動かなくなるかわからない。

Sunはいまだに開発者のお遊びのノリで作っているのか? 1.4.2ユーザには 1.4.2系列の最新メンテナンスリリース(現時点で 1.4.2_15)を案内し、1.5.0ユーザには 1.5.0系列の最新(JRE 5.0 Update 12)を案内するべきだろう。少しは Microsoftのやり方*4を見習ったらどうか。

JREがこんな糞設計になっていることも、厚生労働省などが、「自動更新機能を無効にしてください」と言わざるを得なくなってしまっているもう一つの原因だ。

画面キャプチャ
図4: 厚生労働省が自動アップデートを無効にするよう指示している様子*5

Q. JRE(Java Runtime Environment)の最新バージョンへの更新のお知らせが表示されるのですが、どのようにすればいいですか?

A. 最新バージョンへの更新は行なわないでください。

JREのバージョン1.4.2をインストールすると、自動更新機能が働き、JREのバージョンが上がってしまう場合があります。

自動更新機能を無効にする手順をご案内しますので、設定のご確認と変更をお願いいたします。

(略)「自動的にアップデートする」のチェックボックスに印がついていたら、印を外してください。 (略)

厚生労働省電子申請・届出システム よくあるご質問

これは Sunが悪い。2年前にも書いていたように、Sunの大口顧客であるところの政府やITゼネコン会社たちが設計変更を要望するべきだ。このような重要な要望に対して耳を傾ける様子がないのなら、そのようなベンダの製品はこのようなソフトウェア開発で使わないよう避けるべきだろう。

*1 一昨年2月の日記「サポート中止ソフトをこれからも入れさせる最高な裁判所」で書いたように、開発者向けのダウンロードサイトから期限切れのJREをインストールさせており、2度にわたって電話で抗議したのに、いまだにそのままにしている。

*2 1.に該当しないところ、つまり、「_XX」というバージョンが変わっても動くようにアプリケーションを作っているところについては、今回のような意味での告知の義務はないだろう。私としては、そのような場合であっても、せめて政府くらいは、インストールさせているソフトウェアの脆弱性情報の提供をした方がよいと思うのだが、それは、Acrobat Readerに脆弱性が見つかったときにもそうするべきだというのと同じ程度の要望であって、厚生労働省がしなかった告知とはレベルが違う。

*3 「厚生労働省電子申請・届出システム利用規約」で「エンドユーザは、次の各号に掲げる行為を行うことはできません」として、「本ソフトウェアに改変を加えること並びに逆コンパイルまたは逆アセンブルを行うこと」とされているが、今回のような事実の確認をする行為が妨げられるのは正義に反するので、公然と無視する。

*4 Windows XP SP1がサポート期限内だったときは、SP2が出ている時点でも、MicrosoftはSP1用のセキュリティアップデートを出していた。

*5 7月5日のNHKニュースウオッチ9で、この画面を映し出して「最新バージョンへの更新は行なわないでください」とは何事か!と批判されていたのに、厚生労働省は現在もこの指示を出したままにしている。

本日のリンク元 TrackBacks(100)

2007年07月10日

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

一昨日の日記の続き。結論から言うと、今日気付いた事実により、一昨日の最後の節「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

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

したがって、「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 VersionFamily 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.2clsid:CAFEEFAC-0014-0002-FFFF-ABCDEFFEDCBA
    5.0clsid:CAFEEFAC-0015-0000-FFFF-ABCDEFFEDCBA
    6.0clsid: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" を指定するよう書き換える。

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

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

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

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

  1. (同上)

    • 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アプリケーションそれぞれでの、使用バージョンの考え方が以下の文書にまとめられている。

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

追記(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>

表1: 各Javaアプレット起動タグにおける各ブラウザの挙動
OBJECTEMBEDAPPLET
Internet Explorer図3の警告無視される6 Update 2で起動
Firefox 2.0無視される「ここをクリックするとプラグインを…」の表示6 Update 2で起動
Opera 9無視される6 Update 2で起動6 Update 2で起動
Safari「?」アイコンで起動せずコーヒーの絵が出て起動せず6 Update 2で起動

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

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

表2: 同、JRE 1.4.2_15をインストールした場合
OBJECTEMBEDAPPLET
Internet Explorer1.4.2_15で起動無視される6 Update 2で起動
Firefox 2.0無視される「ここをクリックするとプラグインを…」の表示6 Update 2で起動
Opera 9無視される6 Update 2で起動6 Update 2で起動
Safari「?」アイコンで起動せずコーヒーの絵が出て起動せず6 Update 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の文書が以下にある。

以下によると、「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>]

*1 あるいは、猫には砂箱で用便させるという意味?

*2 逆に、「.html」はプログラムコードを含むので開いてはいけないファイル形式である。

*3 公表日くらい書けよ。見た人がいつの話かわからんだろ。

*4 別件の類似告知と同じタイトルで区別できん。読む人の視点に立って書けよ。

*5 次の方法で確認できる。JREを全てアンインストールした状態で、「登記申請書作成支援ソフトウェア」をインストールし、Javaアプレットの埋め込まれたページを表示したときに、Javaアプレットが作動しない。

*6 2003年10月から11月にかけての議論が「[memo:6630] 厚生労働省の「申請用プラグイン」に含まれるSunのJava VMは脆弱性の影響を受けないのか」にある。

*7 原因は使用した部品にあるわけだが、修正の責任はそれを組み込んでいるアプリケーションの提供者にある。

*8 民間ならば不便なことは死活問題だが、役所にとっては利用されなくても平気なので気にされない。

*9 この挙動を利用して、各官公庁の電子申請や入札システムの必要とするJREバージョンがバラバラで同時に使えない問題を解決するという方向性もあり得たが、これ自体が危険な挙動であったわけで、そのような方向性は正しくなかった。

*10 以前は、JRE 5.0インストール後に、JRE 1.4.2をインストールすると、後からインストールした方が起動してしまう問題があったような記憶があるが、ここでは、Java Plug-inは常に新しい方のもので動くということのようだ。

*11 これは、攻撃者のページかもしれないのだから、「はい」がデフォルトというのはいかがなものか。

*12 そのような指揮は誰がとっているのだろう? ここはひとつガツンとやっていただきたい。

本日のリンク元 TrackBacks(100)

2007年07月15日

電子申請のJRE脆弱性放置、各都道府県の状況

5日から報道された問題。各都道府県ではどうなっているのか。短時間でざっと調べてみた。(忙しいと逃避してしまう。NISCが調査するとの報道だったので任せておけばいいところ、つい調べてしまう。)

上から順に悪い事例。下は良い事例。このように良い事例もあるのだから「○○が悪いので」は言い訳にならない。

5日の厚生労働省と同じ状況で現在も放置中のところ

パッチバージョン固定でJREを使用させ、未対応かつ回避策を告知していないところ

  • 熊本県は、JRE同梱のインストーラを配布中。JRE 1.4.2_10 のJREを同梱。6日付の「重要なお知らせ」で、「最新のJREに対応した電子申請のソフトウェアを、今月中を目処に準備を進めております」としているが、回避策を案内していない。

    重要なお知らせ  (平成19年7月6日)

    「よろず申請本舗」ではサン・マイクロシステムズ社のソフトウェアであるJRE1.4.2_10を利用しています。既報の通りこのバージョンに脆弱性があることが確認されており、悪意あるWebサイトを閲覧すると、脆弱性を悪用し、外部からパソコン内のファイルを読み書きができるなどの可能性がありますので、不審なサイト等には充分に注意して下さい

    なお、「よろず申請本舗」では、最新のJREに対応した電子申請のソフトウェアを、今月中を目処に準備を進めております。準備が整い次第、本サイトでご案内いたしますので利用者の皆様にはご理解いただきますようお願い申し上げます。

    公表日不明の「お知らせ」にて、

    よろず申請本舗の一部の手続で利用している「Java 2 Runtime Environment(JRE)のバージョン1.4.2_10についてセキュリティ上の脆弱性があることが判明しました。本脆弱性に対応した新しい JREの提供につきましては、準備が整い次第本サイトでご案内いたしますので、それまで提供元が不明であるなど不審と思われるアプレットは絶対に実行しないように注意してください

    とあり、2005年2月19日の日記「官公庁の担当者は署名なしアプレットの存在を知らないのか」で書いたことと同じ勘違いをしていて、事の重大性を理解していないと思われる。

  • 山口県は、JRE同梱のインストーラを配布中。JRE 1.4.2_13 のJREを同梱。13日付の告知で次のように案内しているが、これは誤り。_13 以降に見つかっている脆弱性は、Java Web Startに関するものだけではない

    2.この問題の対応策

    やまぐち電子申請サービスでは、「Java Web Start」は利用いたしませんが、より安全を確保するために次の手順に従って、ご利用されるブラウザから Java Web Start アプリケーションが起動しないように処理を行ってください。

パッチバージョン固定でJREを使用させ、報道後に回避策の告知はしたが未対応のところ

  • 岡山県は、「ご利用ガイド」のページで、JRE 1.4.2_10 のインストールを促しており、以下のURLで JRE 1.4.2_10 を現在も再配布中。期限切れのバージョンであることの説明はない。
    http://www.pref.okayama.jp/e-entry/guidance/download/j2re-1_4_2_10-windows-i586-p.exe

    トップページには「重要なお知らせ」として6日付で「公的個人認証サービスに係る重要なお知らせ」という案内を出しているが、「詳細は厚生労働省のホームページのとおり」として他人事。

    1.岡山県・市町村電子申請システムでは、公的個人認証サービスを用いた電子申請を行う場合は、サン・マイクロシステムズ社のソフトウェアである JRE1.4.2_10を利用しているところですが、同様のソフトウェアを利用する厚生労働省からJREの脆弱性について発表がありました。詳細は厚生労働省のホームページのとおりですが、被害回避のため、公的個人認証サービスを用いた電子申請を行わない場合は、JREを削除していただきますようお願いいたします。JREの削除情報は厚生労働省のホームページを参照してください。

    今後は、サン・マイクロシステムズ社が公表するJREの脆弱性を解消する情報が入り次第、情報提供させていただきますので、ご理解ください。

    その情報は一昨年に公表されている。

  • 北海道は、事前準備の説明ページで、JRE 1.4.2_10 のインストールを促しており、以下のURLで JRE 1.4.2_10 を現在も再配布中。期限切れのバージョンであることの説明はない。
    https://shinseido.ar.pref.hokkaido.lg.jp/soudan-res/html/tools/j2re-1_4_2_10-windows-i586-p.exe

    トップページには、6日付で「Sun Microsystems社「Java2 Runtime Environment」のぜい弱性について」の告知があり、無効化するか削除する手順を紹介している。

  • 千葉県は、JRE同梱のインストーラを配布中。JRE 1.4.2_10 のJREを同梱。11日の「重要なお知らせ」で、「セキュリティ上の脆弱性があることが公表されています」として、Java Plug-inをを無効にする設定を紹介。

パッチバージョン固定でJREを使用させ、報道前から回避策の告知はしているが未対応のところ

  • 佐賀県は、「電子申請を行うための設定」のページで、JRE 1.4.2_06 のインストールを促しており、以下のURLで JRE 1.4.2_06 を現在も再配布中。JRE 1.4.2_06 は特に古く、脆弱性が公表されたのは2005年3月。
    http://www.pref.saga.lg.jp/portal/public/HP/j2re-1_4_1_06-windows-i586-i.exe

    同じページの下の方で、「JRE使用の注意事項について」として、次のように説明している。_07 の記述があることから、2005年に書かれたものと思われる。

    佐賀県電子申請システムで利用しているバージョンについて

    現在、佐賀県電子申請システムで動作確認しているJREのバージョンはJRE1.4.1_06です。 佐賀県電子申請システムでは、JREを上記の脆弱性対応バージョンにした場合、申請データの画面が一部、表示されないことが確認されています。 上記のバージョンでの正常動作を確認するまでの間、次の「対処方法」を実施いただくようお願いいたします。

    対処方法

    提供元が不明で不審と思われるアプレットは、絶対に実行しないでください。佐賀県電子申請システムを利用された後、当該JREを非稼動状態にしてください。

    「絶対に実行しないでください」というのは、2005年2月19日の日記「官公庁の担当者は署名なしアプレットの存在を知らないのか」で書いたことと同じ勘違いをしていると思われる。

  • 新潟県は、発表日不明の告知ページ(Last-Modified: は 2007年5月18日 14:13:37)にて、「動作確認しているJREのバージョンは JRE1.4.1_07、JRE1.4.2_03、JRE1.4.2_10」であるとして、Javaの無効化を案内している。この案内がいつからあったかは不明だが、archive.orgの記録によると、2007年3月4日の時点では存在しなかったもよう。

    新潟県申請・届出システムでは、JREを最新バージョンにした場合、申請データの送信ボタンでエラーが表示されるなど、一部機能が正常に動作しないことが確認されています。

    最新バージョンにおける動作確認につきましては、鋭意実施いたしますが、それまでの間は下記の対応を実施いただくようお願いいたします。

    (1) 提供元が不明であるなど不審と思われるアプレットは、絶対に実行しないでください。

    (2) 新潟県申請・届出システムを利用された後、当該JREを非稼動状態にするようにしてください。

    「絶対に実行しないでください」は、2005年2月19日の日記「官公庁の担当者は署名なしアプレットの存在を知らないのか」で書いたことと同じ勘違いをしているもよう。

  • 滋賀県は、設定手順の説明ページで、

    滋賀県電子申請システムでは、ご利用のパソコンに申請時の入力内容を保存したり、電子署名を行うために、ご利用のパソコンに「申請者用プログラム」とJRE(Java Runtime Environment Version1.4.2_06)をインストールする必要があります

    ※プログラムのインストールをさせる際に、JRE(Java)の最新バージョンでインストールするかを確認する場合があります。(利用者側の環境によって異なります。)その際には、必ず「いいえ」とし最新のバージョンでインストールしないようにしてください

    として、マニュアルでも「JRE 1.4.2_06 以外のJRE がインストールされている場合は、事前にJRE をアンインストールしてください」としている。JRE 1.4.2_06 は特に古く、脆弱性が公表されたのは2005年3月。2007年5月10日付のお知らせで、「当面の間は、下記の対応を行っていただきますようお願いします」として、Javaの無効化を案内している。

  • 宮城県は、専用ソフトの配布ページにて、JRE同梱のインストーラを配布中。JRE 1.4.2_13 のJREを同梱。トップページの「インフォメーション」欄に以下の記述があるが、発表日は不明。(報道後?)

    インターネットセキュリティに関する重要なお知らせ

    現在電子署名を行う電子申請手続用にダウンロードして御利用頂いております「宮城県電子申請システムインストーラ」につきまして,その中に含まれている米国 Sun Microsystems社のソフトウェア(JRE1.4.2_13)にセキュリティ上の脆弱性があることが同社から公表されました。サン・マイクロシステムズ社の公表内容はこちら(英文)

    宮城県では,この問題に対応した新しいインストールプログラムを提供準備中です。 電子署名の必要な申請手続を御利用される方は,大変お手数ですが宮城県電子申請システムを利用される時以外はJREをアンインストールされますようお願い致します。

  • 鹿児島県は、JRE1.4.2_11 を使用させているところ、2006年12月21日と2007年5月31日付で、脆弱性の存在を告知し、「申請が終わられましたら、JREをアンインストールしていただきますようお願いいたします」としている。

パッチバージョン固定でJREを使用させているが報道後に最新版に対応したところ

  • 長崎県は、公表日不明のページ(Last-Modified: は 2007年7月10日 12:53:44)にて、

    長崎県電子申請システムでは、Sun Microsystems社のJava 2 Runtime Environment(以下「JRE」という。)1.4.2_10をインストールしていただき、利用しているところですが、JRE1.4.2_14以前の複数のバージョンにセキュリティホールがあることを確認しました。(略)

    現在、長崎県電子申請システムのサイトからJRE1.4.2_10のダウンロードを一時停止し、セキュリティホールが修正されたバージョンのJREを早期に提供できるよう準備をしております。

    として削除方法を案内していたが、利用方法の説明ページでは既に _15 に対応し、JREを自サイト上で再配布している。
    http://eap.pref.nagasaki.jp/download/j2re-1_4_2_15-windows-i586-p.exe

  • 群馬県は、11日付のお知らせで、「JREの最新版JRE1.4.2_15へのバージョンアップを行ってください」と対応。JREを自サイト上で再配布している。
    https://www.e-gunma.lg.jp/portal/upload/1/j2re-1_4_2_15-windows-i586-p.exe

  • 福岡県は、JRE同梱のインストーラを配布中。JRE 1.4.2_15 のJREを同梱。14日付の「重要なお知らせ」で、「現在、このページでは最新バージョンのJRE(1.4.2_15)を使用した「申請者用プログラム」を提供しています」としている。

  • 神奈川県は、JRE同梱のインストーラを配布中。JRE 1.4.2_15 のJREを同梱。6日付の告知で、「このたび、J2RE1.4.2_14以前について報告されている脆弱性への対応として、本システムが推奨するJ2REのバージョンを「J2RE1.4.2_14」から「J2RE1.4.2_15」へ変更することとなりました」としている。

  • 沖縄県は、JRE同梱のインストーラを配布中。JRE 1.4.2_15 のJREを同梱。6日付の告知で、「J2RE1.4.2_15への対応を実施しました」としている。

パッチバージョン固定でJREを使用させているが報道前に最新版に対応したところ

該当なし。

パッチバージョン固定にしていないか不明だが、最新版への対応ができたと告知しているところ

  • 富山県は、6日付のお知らせで、「これまでは、JRE1.4.2_10を推奨しておりましたが……このたびより最新のバージョンであるJRE1.4.2_15に対応しました」としている。

使用するJREバージョンを1.4.2と指定してパッチバージョン固定にしていないところ

  • 大分県は、「バージョン1.4.2_15以上を用いてください」としており、13日付で「利用推奨環境をJRE1.4.2_15以降に変更」としている。

  • 鳥取県は、「JRE (Java Runtime Environment) 1.4.1_06以降」と指定していて、6日付の案内で「当該JREを無効状態にしてください。またはこの脆弱性に対応している1.4.2_15をご使用いただくようお願いします」としている。

  • 奈良県は、1.4.2_XX の任意バージョンで動作可能なような書き方になっていて、6日付で「1.4.2_15 にアップグレードされることをおすすめします」としている。

  • 秋田県は、「本システムで推奨しているバージョンは「J2RE1.4.2_15以上」となります」としている。

  • 東京都は、「本システムで利用可能なJ2REのバージョンは1.4.2_XX(XXは13以上) です」と指定している。

  • 三重県は、「必要なバージョンは JavaTM2 Runtime Environment Standard Edition Version 1.4.1以上です」としていたところ、6日付のお知らせで次のように案内している。

    三重県電子申請・届出システムでの動作環境はJRE/SDK1.4.1以降で、また現在最新のバージョンであるJRE/SDK1.4.2_15で動作確認済みです。

  • 香川県は、1.4.2 の最新版のインストールを促している。JREに新バージョンが出るたびに頻繁に告知が出ている。

  • 宮崎県は、JRE 1.4.2 の最新版をインストールするように案内している。

使用するJREバージョンを指定していないはずが、説明が誤っているところ

  • 京都府は、Microsoft Java VMでも動作するとしており、どのJavaバージョンでも動作するようだが、なぜか、事前準備の説明ページで、開発者向けの期限切れバージョンのダウンロードサイトへリンクしており、ここには必ず最新版より1つ前のバージョンしか置かれていないのだから、たいていの場合脆弱性のあるバージョンであり、極めて不適切。リンク先冒頭に書かれている英文が読めないらしい*1

    JREの入手と設定

    Java実行環境としてJREをご使用になる方は、Sun Microsystems社のダウンロードサイトからダウンロードし、インストールしてください。

    Sun Microsystems 社のダウンロードサイト
    http://java.sun.com/products/archive/j2se/1.4.2_14/index.html

    上記サイトのページに対象のバージョンが存在しない場合は、以下よりダウンロードしてください。
    http://java.sun.com/products/archive/index.html

使用するJREバージョンを指定していないところ

  • 福島県栃木県兵庫県島根県徳島県は、Microsoft Java VMでも動作するとしており、どのJavaバージョンでも動作するらしい。

    • ただし、兵庫県は、JRE 1.4.2_15のダウンロード方法をパッチバージョン固定で指定しており、不適切。

      JRE1.4.2_15を推奨しております。下記サイトよりダウンロードしてください。(略)

      ◆JRE1.4.2_15 のダウンロード(推奨)
      http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=j2re-1.4.2_15-oth-JPR&SiteId=JSC&TransactionId=noreg

      ◆JRE のダウンロード
      http://java.sun.com/products/archive/index.html

      また、 http://java.sun.com/products/archive/index.html は開発者向けの期限切れバージョンのダウンロードサイトであって、ここを紹介するのは著しく不適切。ページ冒頭の英文が読めないらしい*2

    • ただし、福島県は、NT4.0の場合に JRE 1.4.2_03 でないと駄目だとされている*3

    • ただし、島根県は、6日付の告知で、なぜか、「バージョン1.4.2_15の動作確認が取れておりません」「電子申請利用終了後はバージョン1.4.2_14をアンインストールするなどの回避策をとっていただきますようお願いします」としている。Microsoft VM でも動くものが、JRE 1.4.2_14 から _15 への変更で動かなくなるとは思えないのだが。

    • ただし、徳島県は、JREのインストール方法の説明で、開発者向けの期限切れバージョンのダウンロードサイトを案内しており、英文が読めないもよう。

      ※ 上記サイトのページの内容は、予告なく変更されることがあります。対象のバージョンが存在しない場合は、以下よりダウンロードしてください。
      http://java.sun.com/products/archive/index.html

  • 石川県は、JRE 1.4.2 や JRE 5.0 の最新版のインストールを促している。

  • 山梨県は、「現在やまなしくらしねっとではJRE 5.0 Update 12で動作確認済みです」としている。

  • 静岡県は、「最新版のJREを「サン・マイクロシステムズ社」のダウンロードサイトよりダウンロードし、同サイトのインストール方法に従ってインストールを行ってください」とだけ言っている。

番外

  • 山形県岩手県茨城県埼玉県岐阜県愛知県和歌山県広島県愛媛県はJREを使用していない。

    ただし、山形県は、「AdobeReader8.1へはアップデートなさらないようにお願いいたします」としているが、これは大丈夫なのだろうか?

    また、広島県は、次のように脆弱性のあるAcrobat Readerの使用を推奨している。

    ・Adobe Reader6.0.1〜(6.0.1〜6.0.5推奨)
    ・Adobe Reader7.0

    ※Adobe Reader8.0の提供が開始されておりますが,本システムでは正常に作動しない場合がありますので,御注意ください。なお,Adobe Reader8.0のサポートにつきましては,動作確認終了次第,改めて御案内させていただきます。

  • 青森県、福井県、長野県、高知県には電子申請システムがないもよう。

全体を通して見ると、類似の対応をしているところには同じデザインのページがあったりして、共通のベンダーが関与しているように思える。

関連:
厚生労働省の脆弱性放置は何が問題とされているのか, 2007年7月8日の日記
続・厚生労働省の脆弱性放置は何が問題とされているのか, 2007年7月10日の日記

訂正(16日)

  • 広島県が「使用するJREバージョンを指定していないところ」に混入していたのを取り消し。
  • 京都府を「使用するJREバージョンを指定していないところ」から「使用するJREバージョンを指定していないはずが、説明が誤っているところ」へ移動。Microsoft VMでもよいとしているのに、なぜか、インストール方法の説明では archive から _14 をインストールさせている。

*1 2005年2月18日の日記「サポート中止ソフトをこれからも入れさせる最高な裁判所」参照。

*2 2005年2月18日の日記「サポート中止ソフトをこれからも入れさせる最高な裁判所」参照。

*3 サポート期限切れのOSの利用はやめるよう言うべきだろう。OSに脆弱性があれば、電子申請システムも危険にさらされる(セッションハイジャックや、キーロガーを仕込むトロイなど)のだから他人事ではない。同様に、Netscape Navigator 4.x も脆弱性が発見されたままサポート期限切れなので使用不可にするべきだ。

本日のリンク元 TrackBacks(100)

2007年07月25日

日記予定

忙しくて書く時間がない。しかし書かなければ。

  • 「ミクシーラボ」と「nwitter」の違法性に関する検討(不正アクセス禁止法の立法趣旨に照らして)
  • WOWOWコミュニケーションズの「サイト利用規約」は会議室で決めたのか?(ライセンス違反というオマケ付き)

本日のリンク元 TrackBacks(100)

最新 追記

最近のタイトル

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
最新 追記