パスワードを忘れた? アカウント作成
10017 story

法務省と複数の県の電子申請用ソフトに脆弱性 51

ストーリー by Oliver
お上の威光もバグには無効 部門より

Anonymous Coward曰く、"セキュリティホールmemoより:20日のNHKニュース、「電子申請 行政ソフトに不具合」によると、不動産の登記や法人の設立住民票の写しなどをインターネットから申請できる電子申請システムのために省庁や自治体が提供している専用のソフトに脆弱性があり、インストールした利用者のコンピュータがウイルスに感染したり不正侵入の被害を受けやすくなる欠陥があったとのこと。それぞれの告知文は次の通り:法務省の告知岡山県の告知山梨県の告知大分県の告知。その他、国土交通省からも告知が出ている。国交省の告知によると、「平成17年2月28日に独立行政法人情報処理推進機構セキュリティセンターよりJavaセキュリティポリシーの独自設定に関する注意喚起が公表されました。この内容に一部抵触する部分があります」とあることから、IPAの「Java セキュリティポリシーの独自設定に関する注意喚起」に関係する話だと思われるが詳細は不明。それぞれ修正版が出ているので利用している人はアップデートしよう。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • ほぼ1ヶ月 (スコア:2, 興味深い)

    by Anonymous Coward on 2005年04月21日 10時01分 (#725944)
    SUNが脆弱性を公開すると、コアシステムの大元が少し遅れてアナウンスし、それを採用したコアシステム対応認証局http://www.cals.jacic.or.jp/coreconso/linkpage/link5/link5j/link5j-3toiawaseitiran.htm
    のWebページのいくらかにアナウンスが載るまで1ヶ月。
  • 大分県のサイトに飛ぶと自己証明書でSSLを要求してくるんだが・・・
    CAがwww.egov-oita.pref.oita.lg.jpになっとりますが…
    これはこれで問題じゃないのか?
    • 高木さんのblog [takagi-hiromitsu.jp]でも話題になっていますが、自治体の"オレオレ証明書"ですね。

      # ここらへんが酷いので、銀行がとばっちりを受けると

      どこぞのWebページ [srad.jp]は論外としても、ちょっとくらい維持費があがってもいいから、ちゃんと証明書くらい買ってほしいですね(;;
      --
      M-FalconSky (暑いか寒い)
      親コメント
      • 大分県はオレオレ証明書じゃなくてLGPKI発行の証明書ですよ。 # 適当に言う前に確認してみたら?
        • 現状では、普通のユーザがLGPKI発行の証明書とオレオレ証明書を安全に区別するのは難しい。
          ということで、LGPKI発行の証明書もオレオレ証明書扱いしても良いのじゃないかな。
          親コメント
        • >LGPKI発行の証明書ですよ。

          どうすれば「本物のLGPKI発行の証明書」だと確認できますか?
          • LGPKI認証局のフィンガープリントを官報に載せるなりして、
            複数の信頼性の高い手段で確認できるようにしておくのが正解かな。

            Webで公開されているLGPKIのフィンガープリント [google.co.jp]もたくさんあるから、
            これらを複数確認する、というのも手かもしれない。

            この場合、インターネットへの出口で小細工されちゃうとだまされる可能性もあるけど、
            そこまでするクラッカーはいないんじゃないかなぁ。
            親コメント
            • >この場合、インターネットへの出口で小細工されちゃうとだまされる可能性もあるけど、
              >そこまでするクラッカーはいないんじゃないかなぁ。

              そうなんだったら、SSL はそもそも要らないわけで。
              • ネット上で公開されているLGPKIのフィンガープリントのほとんどすべてを偽造しまくる
                トランスペアレントキャッシュみたいなものを置かなければならない、と考えると、わりと面倒です。
                そう言ったトランスペアレントキャッシュを構築できたとしても、
                それをインターネットの出口近くに置くことができるか、という問題もあります。

                十分に多い数確認すれば、それなりの(あくまでも、「それなりの」ですが)信頼性は得られます。

                いつも完璧な信頼性を求める、という条件であれば話は別です。
                そうなってくると、
                    - ブラウザ組み込みの証明書はどうして信用できるのか、とか、
                    - ブラウザ自体はどうして信用できるのか、とか、
                    - プリインストールのOSが汚染されていないことはどうやって保証するのか、とか
                    - 非プリインストールのOSのメディアは汚染されていないのか、とか、
                他にもいろいろ考えるべきことはありますね。
                親コメント
              • > と考えると、わりと面倒です。

                いやいや、全然簡単ですよ。

                線抜いて、間にマシンを挟んで、特定のバイト列を置換するフィルタしながら中継するルータみたいなものを動かすだけですね。

                無線LANだとまたいろいろできそうだし。
              • > いやいや、全然簡単ですよ。

                おお、言われてみれば、確かに簡単そうですね。
                でも、設置するのはそんなに簡単じゃないと思います。

                > ユーザに落ち度がある場合を、ない場合と一緒くたにするのはやめてくれませんか。

                どれがユーザに落ち度があるケースで、どのケースがユーザに落ち度がないケースですか?
                ヘンなブラウザを拾ってくるのは、ヘンなフィンガープリントを拾ってくるのと大差ないと思います。
                へんなOSを納入されてしまうのと、ヘンなプロキシを回線に挟まれてしまうので、どういう差があるんでしょう?
                親コメント
              • > でも、設置するのはそんなに簡単じゃないと思います。

                簡単な場合もありますよ。自分で考えてみたらどうですか。
                「おお、言われてみれば、確かに簡単そうですね」とまた繰り返しますか?

                > へんなOSを納入されてしまうのと、ヘンなプロキシを回線に挟まれ
                > て
              • > 簡単な場合もありますよ。

                もちろん、そういう場合もありますね。

                ところで、フィンガープリントを画像で表示されたりすると、結構厄介なことになりますね。
                ユーザ名・パスワードの入力時に、人間の手を介させるために、画像表示された文字列を入れるやつ、ありますよね。
                ああ言う風に毎回ノイズを混ぜて表示させると、なおのこと厄介になりますね。

                > 全然違うでしょう。

                どの点を指して言っていますか?私は「ユーザの落ち度」について議論しているつもりです。
                    - ヘンなOS(もしくはブラウザ)を納入されること
                    - ヘンなトランスペアレントプロキシを挟まれること
                のどちらがユーザの落ち度がある場合で、どちらがそうでない場合ですか?
                どっちもどっちだと思うけどなあ。
                親コメント
              • 今回のRyo.Fファンはキレが無いですね。  つってもキレがあった事が有るのか知りませんが…

                ※注:Ryo.Fファン…Ryo.Fを見るととりあえずちょっかいを出してしまうアル中のオッサンのような人。今回のように言葉を小出しにするのが特徴だが、長くかまってもらう為か、はたまたRyo.Fの論調を真似ているのかは不明。どちらにせよただならぬ好意を寄せている事は確か。
              • お前が一番の Ryo.F ファンに見えるが。
          • ここ [lgpki.jp]のアプリケーションCAの証明書をブラウザに一時的に組み込んでアクセスして、なにも出なければ一応正しい。念のためにここ [takagi-hiromitsu.jp]のLGPKI使用サイトすべてアクセスして出ないことを確認すれば、もうちょっとだけ信頼できるかもしれない。
            • それだと、そのマシンが DNSスプーフィング攻撃されてても気付けませんよ。
              • > それだと、そのマシンが DNSスプーフィング攻撃されてても気付けませんよ。

                そりゃそうですね。そうなると証明書はダウンロードではなく、輸送や役所に行って自分で受け取るなど信頼できそうな手段でとるしかないですね。それでも確認するブラウザやOSやPCがクラック済みでそこでだまされるとだめなわけですけど。
              • > ブラウザやOSやPCがクラック済みでそこでだまされるとだめなわけですけど。

                それは気をつけてればなんとかなる場合であっても、
                DNS spoofing は自分だけ気をつけてもなんともならないこともあるからなあ。
                隣の席の奴がトロイを踏んでるときとか。
              • > DNS spoofing は自分だけ気をつけてもなんともならないこともあるからなあ。
                > 隣の席の奴がトロイを踏んでるときとか。

                じゃあどうすれば「本物のLGPKI発行の証明書」を確認できるんですか?
              • > じゃあどうすれば「本物のLGPKI発行の証明書」を確認できるんですか?

                できません。
              • 証明書入りメディアを手渡しで受け取ればいいじゃん。
              • > 証明書入りメディアを手渡しで受け取ればいいじゃん。

                その証明書が本物かどうかは確認できるんですか?
                渡した人が間違えたりうそついてたりしても確認できるんですか?
              • by akudaikan (26016) on 2005年04月22日 0時07分 (#726273)
                全国の役場には地方自治情報センターからフィンガープリントが安全な方法で
                郵送されているはずなので、それの原本の閲覧を請求すればよい。
                親コメント
              • by Anonymous Coward on 2005年04月22日 0時25分 (#726282)
                >> 証明書入りメディアを手渡しで受け取ればいいじゃん。
                >
                >その証明書が本物かどうかは確認できるんですか?
                >渡した人が間違えたりうそついてたりしても確認できるんですか?

                #726070 [srad.jp]の質問自体がナンセンスというか、無理ということですね。

                つまりSSLというのは、つまり「証明書」(A)が正しいなら「それを使った通信路はすり返されていない」(B)ことを証明する(A→B)技術ということで、証明書自体も、認証元(C)が正しければその証明書も正しい(D)ということを証明できる(C→D)技術でしかないということでしょうか。

                この場合、(((「LGPKI」→「LGPKI」)→「大分県」)→「大分県との通信」)ということで、LGPKIがそこで閉じている以上、論理(プログラミングOnly)?ではLGPKIを正しいことを定義することはできないということになるのかな。
                親コメント
              • > この場合、(((「LGPKI」→「LGPKI」)→「大分県」)→「大分県との通信」)ということで、LGPKIがそこで閉じている以上、論理(プログラミングOnly)?ではLGPKIを正しいことを定義することはできないということになるのかな。

                この場合、まさにLGPKIは正しいと定義はしています。
                けど、定義なのでそれを証明する手段はないということでしょう。
                親コメント
              • LGPKI証明書をベリサインかなんかの証明書が効いているSSL通信下で、
                lgwan.jpなどの信頼が置けるドメイン配下のサーバで配布したらとりあえずOK?

                ところで、普通は(A)の正しさを「プリインストールされているブラウザについて来たから」で判断するわけで、
                MicorosoftやAppleが信用できない人は何も信用できないことになるのかな。
                だから、最終的にはOSなり証明書そのものなりのメディアを配布している組織が信用できるかどうかなので、
                >その証明書が本物かどうかは確認できるんですか?
                >渡した人が間違えたりうそついてたりしても確認できるんですか?
                ここまで疑うのならその証明書を使うサービスも信頼できないだろうし、使うのをやめなよと思う。
                親コメント
  • by Anonymous Coward on 2005年04月21日 9時48分 (#725940)
    問題ありません。手作業による申請の方がもっと大きな脆弱製を抱えています。
    • Re:問題なし (スコア:0, フレームのもと)

      by Anonymous Coward
      えっ?
      結果的に申請する為のこちら側のPCが脆弱になるんだって話だけど?

      貴方は手作業で申請を終えたら病気に弱い体質になってるの?(w;
  • by Anonymous Coward on 2005年04月21日 13時33分 (#726045)
    問題のプログラムは
    http://www.pref.okayama.jp/e-entry/ready/jpki-05-java04.htm
    で配布されているようですが、古いものが archive.org にあるようですね。
    http://web.archive.org/web/*/http://www.pref.okayama.jp/e-entry/ready/install.jar
    でもダウンロードしたけど動かし方が分からん・・・
  • by Anonymous Coward on 2005年04月21日 15時40分 (#726086)
    システムにはいつもこういった問題ができてしまうものですが、公官庁系のシステムには特に酷い物が多いように思えます。

    セキュリティの基礎も知らないところが開発するからある程度仕方ないですけどね。

    こうならない妙案ありますかね?
    • by Anonymous Coward on 2005年04月21日 16時33分 (#726102)
      公官庁系のシステムでセキュリティの基礎も知らないところとなると某F社のイメージが強いのですが実際はどこなんでしょう?
      親コメント
    • by Anonymous Coward on 2005年04月21日 20時58分 (#726175)
      元請けから、どんどん下請けに流れてますからね
      大手が受注しても、作ったり運用したりするのはどこかの派遣会社から来た人だし
      なので、運用現場になると大変な状態!!
      モラルも低いのでいろいろとモノがなくなったりします
      そのうち某航空会社のようにボロボロと醜聞が出てくるようになるんじゃないかな
      親コメント
      • モチベーションの問題が大きいかなと思う。
        大きな案件の1モジュールを、仕様定義書だけ渡され作れ言われて
        作ってると、やってる作業が卑屈に思えてきて胸を張れなくなる。
        派遣だと一層っていうのはあるかもしれんけど、基本的に社員でも
        PGレベルではほぼ同条件ですからね。

        ちなみにモノなんかなくなる職場ではなく、むしろ適宜処分しないと
        どんどん資料(一回見れば終わり的な)が積み重なって死ねる。
        でも、成
    • > 公官庁系のシステムには特に酷い物が多いように思えます。

      セキュリティに限らず酷いものが目立ちますね。
      ぼったくられているんでしょうね。

      > こうならない妙案ありますかね?

      できたものの出来栄えを評価しないからなんでしょうね。
      仕様さえ満たしてればどんなんでもかまわないと。
      • by gtk (14477) on 2005年04月22日 13時51分 (#726475) 日記
        今回バレた案件は、配布したインストーラの中で Java JRE をサイレントインストールしつつ、VM のポリシファイルを不適切な形に書き換えるって手合いのもの。
        また、インストーラの内部に Sun JRE が同梱されていることを隠し、readme にある Copyright を悉く官庁のものにするという悪質な手合いのものもあったりする。サイレントインストールするものは Java VM だけとは限らない。さすがに1つしか実例を知らないが、 GPL の保護下にあるコードを改変した上で配布し、なおかつ copyright を (その官庁の名前に) 書き換えるといった豪快なインストーラもあった。

        俺もこの手合いのシステムは一時期当事者だったんであんまり語ることができないんだが、とにもかくにも「非機能要件」に該するものはことごとく「仕様にはないのでよきにはからえ」という形になりがち。

        ここで問題なのは、発注する側も仕様書を書く側も、仕事を丸投げするSIerのエンジニアにもそこらへんに意を払うことがない場合だ。これだと、かのような馬鹿インストーラが横行しても偉い人は誰も気づかない。なにしろ、それが「馬鹿インストーラ」だという認識がないから。

        話を Java VM に戻すが、Sun JRE が予告なくサイレントインストールされてしまうと、その PC に他のバージョンの JRE が導入されていると、その環境を破壊してしまうことになる。自分で注意を払わない限り、複数の環境の JRE を共存させることは難しいし、一部のコンポーネントは共存することができずいきなり上書きされる。
        さすがにこれに気づいて苦情を申し入れた利用者も複数いた模様だが、その対処は FAQ にたった一文「Java 環境は共存できません。これは仕様です。」などと付け加えられて終了した。
        親コメント
  • by Anonymous Coward on 2005年04月21日 19時20分 (#726150)
    JAVA に脆弱性が見つかったから云々っていう告知がしょっちゅう出てるのに、何をいまさらという感じがしないでもないよなあ。
    • by Anonymous Coward on 2005年04月22日 8時54分 (#726379)
      今回のはそれとは違うようですよ。
      JRE の脆弱性は Sun の責任ですし、Sun が告知してますが、
      今回のは法務省や県が製作した独自プログラムですよね。
      それは初ではないかと。

      しかし法務省のものと県のものは別のプログラムなんでしょうか?
      あと、他の県はどうなっているのでしょう?
      同じものを使っているのではない?
      親コメント
typodupeerror

ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ

読み込み中...