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

ワームの発生は止められない 223

ストーリー by Oliver
怠慢/無知という大過失 部門より

k3c 曰く、 "ZDNNに、先日のApacheの脆弱性を突いたワームが登場したのは誰が悪いのか?という記事が出ている。なんでも、この脆弱性を最初に公表したISSという企業が、Apacheに通報してから情報(と不十分なパッチ)を公開するまで2時間しか猶予を与えなかったため、パッチが出てからワームの発生までの期間が短く、一歩間違えば被害は深刻だった可能性がある、のだとか。この記事は事態の経緯を分かりやすくまとめており、その意味では一読の価値はあると思う。…なお、肝心の「誰が悪いのか?」という点については、やはりISSはちょっとせっかちすぎた、という結論になっている。
しかしワタシは言いたい。その結論は間違っている。"

"事態の関係者の中に、ISSよりも問題のある振る舞いをしているヒトがいる。それは、ApacheからAdvisoryが出て、脆弱性をFixした新バージョンが出て、さらにワームが発生しても、実際の被害が発生するまでパッチあるいはバージョンアップで対応せず、脆弱なApacheサーバを放置している管理者だ。あるいはApacheを組み込んだ製品を売っておきながらそれを修正せずに放置して顧客への通達を怠るベンダーだ。
この世に悪意がある限り、既存の脆弱性に対する攻撃が発生しないとは誰にも保証できない。むしろ、遅かれ早かれ必ず発生すると考えた方がいい。ワームの発生は止められないのだ。CodeRedのように強力なワームが発生したら、世の中の脆弱なApacheサーバに片っ端から伝染していく、などという恐ろしいことだって起こらないとは限らない。…これは何もApacheに限ったことではない。コンピューターをインターネットに繋いで使っている限り、ほとんど誰でも被害者に、さらには加害者にだってなりうる。被害が発生してからでは遅いのだ。ワームの発生は止められないが、努力次第で被害は最小限に食い止めることができる。努力を怠ってはならないと思う。…なお、一番悪いのはワームの作者であることは言うまでもなかろう。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2002年07月09日 3時06分 (#121327)

    登場人物を整理しておきます。k3c氏の投稿には下記の人物/団体が登場します。

    • Apache(作者)
    • ISS
    • 駄目管理者
    • 駄目ベンダー
    • ワームの作者

    私はこれにもう1人加えたいと思います。それは攻撃用のサンプルソースコードを書いて公開した人物(Gobbles Security)です。私はワームのソースを見ましたが、ワームは元々あったトロイの木馬か何かに、このサンプルソースコード貼り付けたように私には見えました。攻撃用のサンプルソースコードがあったからこそ、ワームが完成したと言えます。

    k3c氏の定義では「ISS < 駄目管理者 = 駄目ベンダー < ワームの作者」ということですが、サンプルソースコードの作者はどこに挿入すべきか。私はワームの作者の次くらいに悪いと思っています。

    ところで、私の調査では、このワームはW32/Nimda以上には流行ってはいないようです。先週からグローバルIPアドレスを1つ割り当てたマシンでワーム捕獲用のプログラムを走らせているのですが、W32/Nimdaが多数なのに対してScalperと思われるものはわずか3件でした。(もっともワームによる攻撃と攻撃用プログラムによる攻撃を厳密に区別することはできませんが...)

    Windowsと異なりUNIX系OSの場合にはソースは1つでも沢山のバイナリがあるので、ワームはそれぞれに対応する必要があります。今のところワームはFreeBSDだけを対象にしていますが、ワーム内部の構造体の値を調整してちょうどよい値を見つけることができれば、RedHatやらTurboなんぞにも対応できるかも知れません。(そうなる前にまだ修正していない人は脆弱性を修正してほしいものです。)

    • Re:Gobbles Securityは? (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2002年07月09日 7時53分 (#121387)
      ...サンプルソースコードの作者はどこに挿入すべきか。私はワームの作者の次くらいに悪いと思っています。
      賛成。

      これを忘れて管理者の責任問題をとやかく議論するのは論外。自分達の首を絞めあって何がうれしいのか?

      親コメント
      • by visha (779) on 2002年07月09日 8時28分 (#121401) 日記

        気持ちはわからんでもない。が、一方で同じものがアンダーグラウンドでのみ流通するくらいなら、いっそ表に出てくれた方がいいとも思う。少なくとも敵の手口をノンケな管理者が知ることができるメリットはある。管理者ならアンダーグラウンドにも精通しとけ、と言われるかもしれないが、それはなかなかコストのかかることでもあるので。それに、例えサンプルコードが表に出ていなくても、その脆弱性が消えてくれるわけじゃないからね。

        ということでサンプルコードの作者を非難する気はあまり起きない。

        親コメント
        • by takenoko (9775) on 2002年07月09日 10時15分 (#121470)
          気持ちはわからんでもない。が、一方で同じものがアンダーグラウンドでのみ流通する くらいなら、いっそ表に出てくれた方がいいとも思う。少なくとも敵の手口をノンケな 管理者が知ることができるメリットはある。
          一部の有料管理者が情報を得て対策をすることができるとしても、 やっぱり問題となるのは、「だめ管理者」ですね。 結局だめ管理者は対策しないんだから、それによる被害をあらかじめ織り込んでおく必要がある。 社会全体なコストを考えるなら。
          • UG情報のままでワーム(大規模な攻撃)が発生する確率 × 全管理者数 × 対応コスト
          • 攻撃手法が公開されたときにワームが発生する確立 × だめ管理者数 × 対応コスト
          のどっちのコストが大きいかが重要かな。確立が両方100%なら親コメントの言うとおりだけどね。 (まぁ、両方の対応コストは同じか?という問題もあるし、 発生までの期間を考えないと詳しい考察はできないと思うが。)

          # あと、サンプルコードでなく攻撃可能なことを論理的に説明するだけで
          # 十分だろうという批判もあると思う。
          親コメント
          • by visha (779) on 2002年07月09日 10時26分 (#121477) 日記

            例えばプロプライエタリなソフトの脆弱性で、パッチもまだリリースされてないのに攻撃コードだけ公開されたら、それは極めて危険な行為だと思うし、管理者に利するところは限りなく0です。だから当然ですが攻撃のサンプルコードの公開の是非は、そのタイミングも含めてあくまでケースバイケースです。

            # あと、サンプルコードでなく攻撃可能なことを論理的に説明するだけで
            # 十分だろうという批判もあると思う。

            論理の正しさを確認するのと、プログラムコードの正しさを確認するのと、どちらかより簡単で確実性が高いかを考えると、必ずしも論理的説明で充分とは思えません。

            親コメント
  • by Anonymous Coward on 2002年07月09日 2時40分 (#121314)
    独善的な意見ですね。
    誰もが、サーバーの管理をして給料をもらっているわけではない。 サーバー管理より優先度が高い別の仕事をメインにやりながら サーバー管理もやらされている人は少なくない。
    日がな一日セキュリティホールつぶし遊びをしていれば ソレで済む暇なオタクばかりじゃないんだよ、世の中は。
    •  サーバ管理関連は素人なので,以下は外しているかもしれませんが。

       例えば,ある会社で業務で車を使っている人が,何らかの致命的な欠陥によりリコールの発生した車をそのまま使いつづけて事故を起こしたら,それは誰の責任でしょう。メーカが顧客への徹底通知&車の回収を行うのは当然として,致命的な欠陥があると知りながらその車を運転しつづけ,その欠陥が原因で事故が起きた場合,運転者や会社に責任はまったく無いのでしょうか。

       インターネットに接続されているサーバは,ネット上に公開されているサービスを受ける/自ら公開する存在ですが,同時にウイルスや何らかのセキュリティホールによる攻撃も受ける/自ら攻撃する可能性のある存在でもあります。ワームやウイルスが増殖したときに被害を受けたサーバは,そのまま加害者側になるかもしれません。

       元記事のAC氏が憤るべきは『サーバを管理してる暇なんて無いよ!』では無く,自身の勤める会社なり機関なりに『サーバを管理するのに十分必要なリソースをくれよ!』なのではないでしょうか。

       この不況下でサーバ管理に十分なリソースをさけない会社等もあるのは分かりますし,業務のかたわら必死に管理者を勤めている方々のご苦労は察します。だからといって,サーバ管理の責任がまぬがれる訳では無いと思います。

       インターネットに接続されたサーバがこうまで日常業務に必要不可欠な存在となった今日においても,その管理リソースがこうまで軽視されている方がおかしな状況なのでは無いでしょうか。

      # 個人的には,ベンダ側がもっと責任をもってユーザにセキュリティ情報をリリース/ケアするべきだと思ってはいます。
      親コメント
      •  例えば,ある会社で業務で車を使っている人が,何らかの致命的な欠陥によりリ コールの発生した車をそのまま使いつづけて事故を起こしたら,それは誰の責任で しょう。メーカが顧客への徹底通知&車の回収を行うのは当然として,致命的な欠 陥があると知りながらその車を運転しつづけ,その欠陥が原因で事故が起きた場合 ,運転者や会社に責任はまったく無いのでしょうか。
        セキュリティ問題の場合、「致命的な欠陥」だけでなく、例えば車が大爆発を引き起こす (周囲に甚大な被害を及ぼす)可能性があるようなことに発展してしまうわけだから、 もちろん対策をしない運転手や会社が悪いのは当然だけど、 じゃぁ販売元は欠陥の発表とリコールの通知だけして、無視した人はそのままにしといても いいのか?と言う話でしょう。

        まぁ、ApacheファウンデーションやISSに欠陥品の回収を全てやれと言うつもりは無いけど、 少なくとも対応を怠ける管理者がたくさんいることを前提に行動すべきではない?
        親コメント
    • なーんでこんな卒直な意見が荒らしなんだよ >モデレタ

      というのはさておき、外から見た場合、その組織のサーバ管理者が専任かそうでないかという事情はどうでもよくて、自分とこに迷惑をかけたか否かだけが問題にされるんじゃないでしょうか。つまり、「日がな一日セキュリティホールつぶし遊びをしていればソレで済む暇なオタクばかりじゃないんだよ、世の中は」というエクスキューズは、組織内ではもしかすると通用するかもしれませんが、組織の外からすると「んなお宅の事情はウチにはどーでもいい。問題は管理不行届きなお宅のサーバを踏台に、ウチに攻撃があったってことだ」ってな話になるでしょう。だから、そーいう事情は内部で解決しとくべきなんじゃ?

      親コメント
    • 単純に言えば、会社側がランニングコストの
      見積りができてないってだけじゃん。

      会社のえらいさんにも受けのいいところが、
      一日 10000 PV 程度のサイト運営にかかるランニングコスト
      (コンテンツ関係は除く)と、
      必要なコストが不足した場合のリスク
      (顧客のマシンにワームを感染させる事例とか)を
      適当に見積もって発表してもらえれば、
      世の中の結構な数の人間が幸せになれるんじゃないだろうか。

      #適当でいいと思うんだよ、
      #どうせ正しい見積もりなんかできないんだから…
      --
      # mishimaは本田透先生を熱烈に応援しています
      親コメント
      • > 単純に言えば、会社側がランニングコストの見積りができてないってだけじゃん。

        その見積もりができ、それに忠実に執務する人間を、
        一部の人間は「オタク」と呼ぶらしい…。

        そのオタクから見ると、
        「他にも仕事があるんだからそんなことしてられっか」と言うヒトの半数は、
        「たいしたこともしてないのに大事なこと」という人間が半数、
        だと思っているだろうな、きっと。
        --
        みんつ
        親コメント
    • だったら、サーバー管理は自分の手に負えないってことを明確に示して、それに時間を割り当ててもらうとか、人員をあててもらうとかを提案するべきではないでしょうか?
      自分で無理(技術的とかだけでなく)なものを引き受けているのが間違いで、その責任はあると思います。
      そういったことをきちんとしておいて、それでも環境を変えてもらえないようなら、それはその会社の責任だと思います。そして会社の信用とかを存分に落としていただきたい。
      親コメント
      • >そういったことをきちんとしておいて、それでも環境を変えてもらえないようなら、それはその会社の責任だと思います。そして会社の信用とかを存分に落としていただきたい。

        そういうことです。
        損失の期待値とコストのかねあいです。

        二次的な加害者(?)の罪or賠償責任が問われない限り
        それほど努力しても経済的には得しないことがかなり
        あるように思う。
        親コメント
      • > だったら、サーバー管理は自分の手に負えないってことを明確に
        > 示して、それに時間を割り当ててもらうとか、人員をあててもらう
        > とかを提案するべきではないでしょうか?

        いや、大学の研究室などではそうもいかないんですよ。
        サーバー管理のための予算などでないために、
        日々の研究に忙殺されながらもWebサーバーや
        メールサーバーの管理を若手研究者が無報酬で
        やっているのが現状です。


        # かく言うボクもそうです。セキュリティ・ホールを
        # 3日以上晒し続けたことはないですけどね。
        --
        ゆーへん
        親コメント
        • by Anonymous Coward on 2002年07月09日 9時44分 (#121446)
          >サーバー管理のための予算などでないために、
          >日々の研究に忙殺されながらもWebサーバーや
          >メールサーバーの管理を若手研究者が無報酬で
          >やっているのが現状です。

           下手なボランティアは制度の確立を遅らせます。
          無報酬でも何とかなってると上層部が思うからいつまでも予算がつかない。いっそ全部止めにすれば、このご時世だし、イヤでも予算をつけてやるか、それができない大学はそれなりの評価をされるということになりますね。

           予算をつけることを阻んでいるのは、ボランティアの存在じゃないんでしょうか?
          親コメント
      • >そういったことをきちんとしておいて、それでも環境を変えてもらえないようなら、それはその会社の責任だと思います。

        責任が会社にあるのに、管理者が詰め腹切らされるのが問題なのでは無いかと…
        --
        戦わずして人の兵を屈するは、善の善なるものなり
        親コメント
      • 自前で手に負えないのなら外部に委託するなりするのが筋でしょうが、信頼できる業者を選ぶのがまた難しかったりするのがなんともジレンマ。一部を除いて十分な実績を示すことでできるところって少ないのですよ。それを見極めることができるくらいなら外部に出すまでもないしね。
        親コメント
    • by Anonymous Coward on 2002年07月09日 9時50分 (#121453)
      外部に接続されているサーバーのメンテ/セキュリティ対策を
      ちゃんと出来ないのであれば,サーバー立てるのは止めましょう.
      (自前でサーバー立てるというのは責任を自分で持つということ
      です)
      世の中にはレンタルサーバー業者がたくさんいるんだから,その
      中かから信頼できるところと契約しましょう. それに,サーバー
      管理をやらせている人間の人件費よりレンタルサーバー代の方が
      安いくらいでは?
      親コメント
    • 出たぁ! 弱者の理論!!

      > 日がな一日セキュリティホールつぶし遊びをしていればソレで済む暇なオタクばかりじゃないんだよ

      技術力の高い /. でこういう意見を振りかざす奴は珍しいな。「ボクちゃん、管理者やってるの・・・でも、技術力が低いから Apache のバージョンを上げるだけで一日かかっちゃうの・・・だから、古いバージョンのままで動かさせて・・・だけどみんな攻撃してこないでお願い。管理者より」というわけか。

      他の掲示板に行ったら?

      せめてニュースで騒いでいる問題ぐらいは対処しなよ。それも出来なきゃ、管理者やめな。

      親コメント
    • by kamira (6480) on 2002年07月09日 11時59分 (#121547) ホームページ
      元トピが独善的な意見である事は概ね同意です。
      ただ、こちらの書き込みをされた方の文章も独善的ですね。

      今回の問題はかなり広域なサーバーに影響を与えるにも関わらず、
      修正まで公開を待てなかったISSに多少の問題があった様な気がします。
      以前、自分もセキュリティ関係でとある会社のソフトウエアに報告をした事がありますが、
      相手の反応を待って修正パッチが公開された頃に、警鐘の意味を込めて
      「この様なセキュリティホールがある」と謳った事があります。

      私の所属する会社でもApache 1.3.24(FreeBSD)が動いております。
      これ、一刻も早くバージョンアップしたいのですが、
      サーバー自体は取引先会社の物です。
      サービス提供を行っている以上、勝手にサーバーを止める事はできません。
      となると、取引先会社担当に承認を貰わなくてはいけませんが、
      まず「そういった事に疎い」担当の場合、今回の重要性を理解してもらえません。
      かかるかかからないかわからないワームより、目下のサービスが止まる事の方を
      重要視します。
      管理者から何度も問い掛けても難しい事って多々あるんです。

      と、ここで説いても「それは会社の体質が」とか「管理者の説き伏せ方が」とかいうレスが
      戻ってくるんだろうなァ・・・(苦笑)

      ちなみに自分でできる範囲のサーバーはすべてアップデート済みです。
      管理を行う以上、忙しいとか個人の怠慢で疎かにしてはいけないと思うので。
      手前のサーバーが壊れるだけなら、そりゃ自業自得ってモンでしょうが、
      ワームの場合、世界に迷惑をかけてしまいますからねぇ・・・。
      親コメント
    • >サーバー管理もやらされている人

      すぐに止めたほうがいいです。
      あなたも、あなたにやらせてる人も、あなたの担当しているサーバを利用している人も、
      あなたのネットワークとつながってる他のネットワーク利用者も
      全員不幸になってますから。

      っていうか、サーバ担当者でしょ、キミ。
      親コメント
    • ふむふむ (スコア:1, おもしろおかしい)

      by Anonymous Coward on 2002年07月09日 3時29分 (#121335)
      > 独善的な意見ですね。
      > 誰もが、サーバーの管理をして給料をもらっているわけではない。
      > サーバー管理より優先度が高い別の仕事をメインにやりながら
      > サーバー管理もやらされている人は少なくない。
      > 日がな一日セキュリティホールつぶし遊びをしていれば
      > ソレで済む暇なオタクばかりじゃないんだよ、世の中は。

      うむ。正論だ。
      最後の2行はな。

      ということは、だ。
      もし君がサーバ管理者であるならばさっさとそういう
      「オタク」に仕事を代わってもらうべきだ。

      どうだろう、そうすればセキュリティホールをつぶせて幸せな
      オタクと、できもしない管理作業を抱えた管理者・・・おっと失礼、
      よりプライオリティの高い仕事を抱えた管理者の2者が幸福になる。

      ん?君に代わる人材がいない?
      よほど程度の低い・・・いや失礼、よほど多忙な会社なのであろう。
      だが、本業に支障のでるような作業を抱えたままで放置する
      会社に君の一生をささげてよいのであろうか?
      いっそやめてしまうのが得策であると思われる。

      何、今の会社を辞めたところで
      君ほどの人材ならば引く手あまたのはずである。
      親コメント
      • 毒舌まじりで素敵です。

        サーバ管理者は中途半端な技術力で行うと職を失う可能性あり。
        --


        .::.:... .::....: .::...:: .::.:.:: .::..:.: .:::..:.
        I 1 2 B H4[keR. :-)
        親コメント
    • by Anonymous Coward on 2002年07月09日 4時01分 (#121348)
        誰もが、サーバーの管理をして給料をもらっているわけではない
        サーバー管理もやらされている人

      会社からやらされているなら、それは仕事。
      給料もらってるって事。
      親コメント
    • by Anonymous Coward on 2002年07月09日 9時17分 (#121429)
      いいから(半)自動でセキュリティアップデートが更新されるようなOSを選んどこうよ。Debian なり。

      # その程度も忙しくて出来ないってんなら管理者なんてやらない方が世の中のため
      親コメント
  • by 335 (4199) on 2002年07月09日 2時48分 (#121317) 日記
    努力はすべきだ。でも全力はムリだ。

    ソフトウェアだけじゃなく人間も不完全。
    時間も能力も有限だしひとによってマチマチ。
    どの程度努力したら努力したといえるの??
    自分より努力せよと主張しているのかな??
    なら世界中の誰よりも早く全ての脆弱性を
    マークしなきゃいけない。ムリだ。
    • 努力はすべきだ。でも全力はムリだ。

      残念ながら、努力したか否か、全力で取り組んだか否かが評価の対象となる時代でもないような気がします。むしろ、ほどほどのコストで必要充分な成果を挙げることが求められるんじゃないですかね?

      で、サーバ管理やシステム管理における「必要充分な成果」って何なのよ、って話になるんだと思うんですが、これこそ雇用主なり発注元なりときちんと合意しとかなきゃならない要件なわけです。じゃなけりゃ、必要なコストも見積れないし、ましてや自分ができる仕事かどうか見極められない。

      世界中の誰よりも早く全ての脆弱性をマークしなきゃいけない。

      もしそうでなければ得られない成果を雇用主なり発注元なりと合意してしまったのなら、その通り。

      ムリだ。

      ならばそういう内容で合意すべきじゃないし、そういう仕事を引き受けてはいけない。倫理とかいう話じゃなくて、自己防衛のために。じゃないと、できない仕事を抱えた挙句に、できないことを咎められるハメになります。合意して引き受けた以上、できないことの責任は、引き受けた当人が背負うことになるわけですから。

      親コメント
  • 実際問題として (スコア:2, すばらしい洞察)

    by FireStorm (7429) on 2002年07月09日 2時54分 (#121319)
    いくらセキュリティホールがあるためにプログラムを入れ替える(パッチを適用する)としても、別のマシンで事前テストを行って要求される機能が全て確実に動作していることを確認してからでないと、そら恐ろしくてサービス提供中のマシンには入れられませんわ。
    • 私の場合 (スコア:2, 興味深い)

      by h-suzuki (7157) on 2002年07月09日 4時05分 (#121349)
      パッチが出たということを確認してから、数時間寝かした後適用します。
      というのも、テストできるような別マシンは存在しないためです。
      また、仮に別マシンが用意されても、サーバ管理を仕事としているわけではないので、メインサーバと同様の環境を構築して動作確認をするのは時間的に厳しいです。
      そこでパッチが出てもすぐには適用せず、MLやwebでの情報を数時間後にチェックし、問題が挙がっていないようなら適用します。
      もちろん、これでは不完全であるのはわかっているのですが、、、
      お金は貰ってないとは言え、不用意にパッチを当ててサービスを止めてしまうのはまずいし、 かといって他人様に迷惑をかけるわけにはいかんのでこんな方法をとっています。
      親コメント
    • by G7 (3009) on 2002年07月09日 9時40分 (#121444)
      蛇足だが、鯖のハードやOSやそこで使ってるアプリが「高価」であればあるほど
      いわゆるテスト環境マシンが用意しにくいってのが有りますね。

      そういう意味では、安いpcに、インストール単位でライセンス料とられるわけでもないオープンソースなos/アプリという組みあわせは、
      いろいろ幸せになりますね。

      俺んとこもプロプラかつLinux非対応な某鯖ソフトがネックでねえ…
      親コメント
  • もう一人の主役 (スコア:2, すばらしい洞察)

    by nekurai (6253) on 2002年07月09日 7時15分 (#121376) 日記

    問題が起きるまで管理する必要すらわかっていない、管理者候補には「毎日落ちてない事を確認できればいいから」とか適当な事を言って仕事を押し付ける、管理しても金を稼げるわけでもないので管理者に金をかけて管理の勉強なんぞさせない、問題が発生すると「悪意のあるハッカーが・・・」と適当にコメントして管理者を処分する、そもそもサーバーを立てる理由が「他の会社も立ててるから」ぐらいのものしかない・・・

    そういう経営者は管理者より悪くないんでしょうか?

  • オープンソース (スコア:2, 参考になる)

    by take0m (4948) on 2002年07月09日 11時10分 (#121509) 日記
    ソースが公開されているのですから、
    自由にソースを解析して、
    セキュリティホールを探し出して、
    勝手に大公開しちゃうことで、
    責められたり、訴えられたりするのでしょうかね?

    ソースを公開するということは、そういう敵意なり
    悪意を持った存在を認めてリスクを認識した上で
    公開しているものなのではないでしょうか?

    使う側もソースが公開されているプロダクツを
    使っている限り、そういう認識は必要なのではないでしょうか?

    開発する側にとって色々都合が良いことがある代りに、
    攻撃する側にとっても都合がよいこともあるはずですし。
    • >ソースを公開するということは、そういう敵意なり
      >悪意を持った存在を認めてリスクを認識した上で
      >公開しているものなのではないでしょうか?
      それはあると思います。

      少なくとも、"だれもが改変自由"の精神を持つなら、たとえバックドアつきを(個別改造版とかいって)配布している人がいても、やめさせる方法はなかなか無いと考えてました。

      こういったのは、コミュニティの努力で啓蒙するとか、メインブランチを多くの人がよくチェックする(セキュリティホール含む)とかしていかないと今の状態すら維持できないのでは?。

      少なくともソースを自由にする権利を取った分、(企業にお金を払った対価としての)メンテナンスとかを自分たちでしっかりやる義務を果たさなくちゃならないと思います。(ISSを非難してもそのホールをふさぐのは結局自分なんだよね)

      #個人的にはソースからコンパイルとかだと
      #とったところ(FTPサーバとか)によっては、どんなコードが入っているか結構気になる
      #確かに自己責任なんだが・・・

      ##最近はプライマリサイトからバイナリをとること多し(笑)

      ほかの誰かの成果には感謝しても、直すのは自分だ!位のつもりでいないとね。
      --
      M-FalconSky (暑いか寒い)
      親コメント
  • by Anonymous Coward on 2002年07月09日 12時51分 (#121597)
    HTMLを転送するのにしか使わないのに、猫も杓子も
    Apache のようなでかい代物を使っている現状が、
    そもそも間違っているような気がする。
    publicfile でいいじゃん。
  • こういったセキュリティホールの公開はすぐに公開したあとの予想できる被害と、公開を控えたとき予想できる被害 (とりあえず公開を1年後とか寝かせておく)のと、どちらが大きいか考慮にいれるべきと思いますが。
    とはいえ、すぐに公開したときのビジネスチャンスというものも少なからず存在します。
    もう結果論に過ぎないのでこれ以上言及しませんが。
  • by brake-handle (5065) on 2002年07月09日 10時47分 (#121491)

    なぜかこれがほとんど話題になっていないのですが、一連の穴騒ぎでISSが出したpatchには抜けがあり、あれだけでは穴を塞ぎ切れないと聞いた記憶があります(確かセキュリティホールmemoから、ただし現在www.st.ryukoku.ac.jpがだんまり中)。そうなると、patchを当てたつもりになって安心していたら実はやられていた...なんてことになってしまうのでは?

    そこまでしてでも速報性は価値のあるものなのかなぁ?

  • by take0m (4948) on 2002年07月09日 10時55分 (#121500) 日記
    サーバを公開できる状態でConnectedにした時点で
    相応の責任が発生しているにも関わらず
    それを理解していない現場と経営サイド双方に
    責任があると思われますが。

    色々なところのWeb系の事業計画書を見ても、
    必ずと言って良いほどサーバ管理「者」のコストは
    含まれていませんし。

    個人情報の流出事件も、ネット以外ではなかなか
    そこまで無頓着になれないと思います。
    電子的な情報に慣れてないということが大きな
    原因かもしれませんけどね。
    もう少し、教育が必要なのでしょうか。
typodupeerror

アレゲはアレゲを呼ぶ -- ある傍観者

読み込み中...