<前の日記(2005年07月11日) 次の日記(2005年07月18日)> 最新 編集

高木浩光@自宅の日記

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

2005年07月17日

官庁はJavaの脆弱性にどう対処すればいいのか

現状、Webを閲覧利用するにあたって、JRE(Javaの実行環境)のインストール を求められるのは、民間商用サイトにおいてはめったにないことだと言ってよ い。それに対し、政府系の電子申請システムを利用しようとすると、大半のケー スでJREのインストールを求められる。これは、ファイルに対する電子署名の 処理をクライアント側で行うようにしたこと、採用したXML形式による署名の ためにJavaライブラリが充実していることなどが原因だろうか。Javaの普及を 願う者としては願ったり叶ったりだが、JREの脆弱性発覚時の体制がWindowsの それほどには確立していないことが、仇となってしまっている。

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

先日の宮城県のケースはともかくとして、 JREをインストールさせている官庁(中央省庁および地方自治体)にとって、 JREに脆弱性が見つかるたびに対応策を告知することは義務であるという考え 方は、概ね普及したようである*1。まことに適切なことである。 しかし、告知には2種類のものがある。Javaのアップデートをしないで対処せ よと呼びかけるものと、アップデートせよと呼びかけるものだ。

前者の告知の内容はだいたい次のようなものになっている。

  • ○月×日、JRE 1.X.X_XX に脆弱性が発見されました。詳細については サンマイクロシステムズ社のページ(英語)をご覧ください。
  • △△省電子申請システムを利用する限りにおいては問題ありません。し かし、悪意ある他のサイトを訪れたときに当該脆弱性によってセキュリティ侵 害を受ける可能性があります。
  • この脆弱性に対策された新バージョン 1.X.X_YY がリリースされていま すが、△△省の電子申請システムでは動作保証をしていません。現在、鋭意 動作確認を行っているところですが、確認が完了するまで下記の対処方法にし たがってください。
  • 信頼できないサイトを閲覧しないでください。
  • 電子申請システムを利用中に他のサイトにアクセスしないでください。 電子メール中のリンクもクリックしないでください。
  • 電子申請システムの利用を終えたら、JREを非稼動状態に設定し、電子申 請システムを利用する間のみJREを稼動状態に設定してください。
  • Java Web Startを非稼動状態に設定してください。
  • ……

こんな複雑で手間のかかることを求めるくらいならいっそ、「当局への電子申 請には、当局電子申請専用のパソコンをご用意ください」とした方が簡潔でわ かりやすいのではないかと思えるくらいだ。

この種の案内を出しているところは中央では以下などがある。

地方自治体もこれに習ってか、同様の告知をしているところが少なくない。 参考: Google検索「java 脆弱性 site:lg.jp」

追いつかない対応

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

  • 警察庁, 電子申請・届出システム

    重要なお知らせ

    警察庁に申請をされる方のパソコンにインストールして利用するJava(TM)2 Runtime Environment(以下,J2RE) 1.4.1_01において、脆弱性が発見されたため、警察庁の電子申請・届出システムは脆弱性が解消されたJ2RE1.4.2_06に対応 いたしましたので、こちらを参照して早急な対応をお願い致します。(平成16年12月13日)

  • 防衛庁, JRE インストール手順

    RE(Java 2 Runtime environment)1.4.1_03が端末にインストールされて いない場合は、下記URLよりJRE1.4.1_03をダウンロードしてインストールしてください

    http://java.sun.com/products/archive/j2se/1.4.1_03/index.html(Windows(all languages,including English)を選択して下さい。

  • 外務省, 利用上の 留意事項(Java実行環境について)

    本窓口をご利用いただくにあたっては、サン・マイクロシステムズ株式会社のダウンロードサイトからJRE version1.3.1_10をインストールしていただく必要が ありますが、ダウンロードならびにインストールの際には下記の事項 にご注意ください。

    * version1.3.1_10以外のJREがインストールされている場合は、事前にアンインストールしてください。

    * 本窓口を利用するためのJREをインストールした後に、異なるバージョンの JREをインストールすると、本窓口が利用できなくなります。ご注意ください。

  • 厚生労働省, 電子申請・届出に必要なソフトウェア (リンク不能な場所 に書かれている文から引用:)

    ※ システムの動作確認は以下の各バージョンで行っています。
    JRE1.3.1_11、JRE1.4.1_07、JRE1.4.2_04
    セキュリティ等の観点から、JRE1.4.2_04でのご利用を推奨していま す。(平成16年6月現在)

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

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

  • 総務省, 動作環境(平成16年9月現在)について

    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と同様にだ。

無責任な製品を国家インフラに使用?

だが、Sun Microsystemsはそれを提供してこなかったように思える。たとえば、JRE 1.4.2_08のリリースノートを見ると、各「_XX」バージョンでの変更点の一覧があるが、 ものすごい数のセキュリティに関係のないバグの修正が並んでいる。こんなの では、動いていたものが動かなくなる確率も上昇するだろう。

そういう事態を避けるために、セキュリティに関わるアップデートは独立して 提供するべきだが、Sun Microsystemsはそれをやっていない。 そういう、開発者のお遊びを続けているままのようなソフトウェアを、国家の 電子申請システムのために一般市民に使わせること自体が、そもそもの誤りで はないか。

Sunがしっかりしていないなら、ちゃんとやれと圧力をかける機会がSunの大口 顧客にはある(私にはない)わけだが、政府やITゼネコン会社たちはそういう 要求をちゃんとやっているのか? 金融庁の告知 にある、

1.この問題による危険性

サンマイクロシステムズ社のホームページにおいて、このソフトの脆弱性が公 表されております。こちらで内容をご確認ください。
http://sunsolve.sun.com/search/document.do?assetkey=1-26-101749-1

という、一般国民への危険性の説明において、英語のドキュメントしか紹介で きないというのは、誰が悪いのか? 日本語版の脆弱性文書を提供しない Sun のような会社の製品を国家のインフラにいつまで使い続けるつもりなのか。そ れが止むを得ないことなのなら、政府が日本語版の脆弱性説明文書を書いて公 表するべきだろう。

本当に動かなくなるのか

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

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

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

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

その追加費用はどのくらいになるだろうか。新バージョンでの動作検証と改修 という追加事業にいくらかかっているか知らないが、仮に初期開発費の2割だ とする。システムの運用予定期間(たとえば2年)内に脆弱性が4回発覚すると 予測したとき、初期開発費の8割増しの費用でトントンということになるが、 実際にはそれより安くできるのではないか。

脆弱性が発覚するたびに毎回お決まりの「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 系を使うよう に指示している。

  • 経済産業省, ITEM2000(Version 2.2.0)の入手方法

    旧バージョンのITEM2000で使用したJavaの動作環境(JRE1.4.1._07以前のJRE)では、最新版のITEM2000が正常に動作しません。

    旧バージョンのITEM2000を使用されていた方は最新版のITEM2000をインストールする前に、ITEM2000 Version 2.1.0とJREの両方をアンインストールし、さらに旧バージョンのITEM2000がインストールされていたフォルダを削除してください。

しかし、先ごろ発覚した Update 1の脆弱性については触れられていない。 これは次のように考えることが可能かもしれない。 JRE 5.0では自動アップデートの機能が Windows Update同様に、タスクバーに 現れるようになった(図1)。

図1: JRE 5.0の自動アップデート機能

これによって、JREのアップデートはユーザの責任ということになったと言う ことが可能かもしれない*3

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

とりあえず、アップデートリリースが出るたびに専用ソフトのCD-ROM(JREが 同梱されているもの)を作り直すということ(以前は行われていたこともあっ た)は、やらなくてもよくなったと言えるかもしれない。ただし、インストー ルと同時にアップデートチェックされるような仕掛けを用意するか、アップデー トの必要性を同梱マニュアルに書いておくべきだろう。

こういったことは省庁横断的に議論されているのだろうか。ベンダー間で集まっ て勉強会とかやっているのだろうか。地方自治体はどうするんだろうか。

*1 Acrobat Readerのインストールを要求 している官庁も、Acrobatの脆弱性発覚時に告知するべきだと思うが、それは 行われていない。

*2 そうした通知が必要ないほどまでに、あるいは、報告さえないほ どまでに、電子申請自体が使われていないのかもしれないが。

*3 しかし、更新確認の頻度が、初期設定では 月に1回と設定されているようなのだが……。

本日のTrackBacks(全3件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20050717]

re: なんでそーなるのッ!!

検索

<前の日記(2005年07月11日) 次の日記(2005年07月18日)> 最新 編集

最近のタイトル

2024年12月02日

2024年11月24日

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

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|04|07|11|12|
<前の日記(2005年07月11日) 次の日記(2005年07月18日)> 最新 編集