タグ

責任に関するmi1kmanのブックマーク (19)

  • グーグル、深刻な脆弱性は60日以内に修正するようベンダー各社に要請 - セキュリティ - ZDNet Japan

    Googleはソフトウェアメーカーに対し、深刻な脆弱性の修正に60日という期限を設けるよう求めるとともに、期間内に修正されない場合はGoogleが脆弱性の情報を公開すると警告している。 Googleセキュリティチームは、米国時間7月20日付のブログ投稿の中で、同社がソフトウェアベンダーとの間で定めている「行動規則」(rules of engagement)に加えた変更点を説明した。この行動規則は、同社がベンダー各社に脆弱性を報告する方法とタイミングについて定めたものだ。同チームは、セキュリティの専門家が「責任ある開示」のポリシーに従うことは、必ずしもエンドユーザーにとって最善の策にならないと主張している。このポリシーの下では、脆弱性は非公開のままベンダーに報告され、報告した側の研究者は、当のセキュリティホールが修正されるまで詳細情報を一般に公開せず待つことになる。 Googleのセキュリ

    グーグル、深刻な脆弱性は60日以内に修正するようベンダー各社に要請 - セキュリティ - ZDNet Japan
  • フリーソフトウエアの「社会的責任」? - 極楽せきゅあブログ

    セキュメモで見掛けたユーザの自由、作者の自由 - Togetterをつらつら眺めて思った>社会的責任 気に入る、気に入らないというレベルの話であれば、「あなたが気に入らなければ{使わなければ|自分で作れば}良いじゃん」と言える。しかし、「脆弱性」が存在したとしたら、そのソフトウエアを知らずに使い続けると自分の大事な情報を盗まれるなどの危険な目に遭う可能性がある。その場合はまさしく「社会的責任」というヤツが生じると考えるべきなのかな。少なくとも使用停止も含めてアナウンスくらいはする必要がある?それをどこまで知らせる?プッシュ型のお知らせまですべき?・・・まあ、少なくとも社会的なリスクを低減させることができるような行動をとるべきなのかなあ。自分が訴えられるとか、そういうリスクを回避するという意味でも。 ソフトウエアを作って公開する、というのには、そういうリスクもあるということなんですかねえ。

    フリーソフトウエアの「社会的責任」? - 極楽せきゅあブログ
  • 高木浩光@自宅の日記 - ジャストシステムはどこへ向かっているのか

    ■ ジャストシステムはどこへ向かっているのか ジャストシステムが、ユーザの安全確保よりも、何らかの別の目標*1に向かっているらしいことは、次の事例で一目瞭然だろう。 こんな言い回しは他で見たことがない。 脆弱性情報を公表することの目的が、まだ修正版の存在を知らされていないユーザに対してアップデートの必要性を周知することにあるということは、(ユーザの立場で考えれば)誰でもわかるはずだ。それなのに、ジャストシステムは、まず先に、「ご安心ください」と言う。(図1の1つめの矢印部分。) Kaspersky Internet Security 6.0 および Kaspersky Anti-Virus 6.0のVista対応版プログラム以前の製品(バージョン 6.0.0.306)で5つの脆弱性が発見されています。この問題に対する修正は、3月14日より無償でダウンロード提供しているVista対応版プログ

    mi1kman
    mi1kman 2007/11/01
    「ソフトウェア製品開発者による脆弱性対策情報の公表マニュアル」がもっと広まってほしいと思う
  • 高木浩光@自宅の日記 - 厚生労働省の脆弱性放置は何が問題とされているのか

    ■ 厚生労働省の脆弱性放置は何が問題とされているのか 目次 今回の報道 過去の経緯 何が問題なのか 当に動かなくなるのか 内閣官房に期待すること 新たな問題(Sun Microsystemsの愚行) 今回の報道 先週、NHKが、厚生労働省の電子申請システムのセキュリティ上の問題点を取り上げていた。 NHKニュース「厚労省 欠陥ソフトを放置」, 2007年7月5日 ニュース7 厚生労働省はホームページ上で特定のコンピューターソフトを提供していますが、このソフトには重大な欠陥があり、利用者がパソコンの情報を盗まれるおそれのあることがわかりました。(略) 厚生労働省は、こうした情報を把握できず、5か月以上にわたって、欠陥が修正された最新のソフトに切り替えたり、利用者に注意を呼びかけたりするなどの対策をとっていませんでした。 NHKニュース「厚労省 欠陥ソフト提供中止」, 2007年7月6日 お

    mi1kman
    mi1kman 2007/07/10
    「今回のような事実の確認をする行為が妨げられるのは正義に反するので、公然と無視する。」
  • 高木浩光@自宅の日記 - ケータイWebはそろそろ危険

    ■ ケータイWebはそろそろ危険 これまでの背景と最近の状況変化 「安全なWebサイト利用の鉄則」にある通り、フィッシングに騙されずにWebを安全に使う基手順は、(パスワードやカード番号などの)重要な情報を入力する直前に今見ているページのアドレスを確認することなのだが、しばしば、「そのページにアクセスする前にジャンプ先URLを確認する」という手順を掲げる人がいる。しかし、それは次の理由で失当である。 ジャンプ先URLを確認する手段がない。ステータスバーは古来よりJavaScriptで自由に書き換えられる表示欄とされてきたのであり、ジャンプ先の確認に使えない。 ジャンプ先URLを事前に確認したとしても、それが(任意サイトへの)リダイレクタになっている場合、最終的にどこへアクセスすることになるか不明。 そもそも、アクセスする前から、アドレス確認の必要性を予見できるとは限らない。普通は、アクセ

  • interNet POLICE 警察庁 インターネット安全・安心相談 過去にあった脆弱性の件 - hoshikuzu | star_dust の書斎

    interNet POLICE 警察庁 インターネット安全・安心相談 のページ ここには過去にXSS脆弱性があり、IPAさんに報告しておりました。 さきごろ取り扱い終了になったもようです。 最近、私は、自称ネット難民ですので、なかなかインターネットに接続できなかったこともあり、残念ながら今日になって、あれれ?と思いまして経過報告を日記にて行うこととしました。 2005年06月17日 警察庁 インターネット安全・安心相談のサイトが立ち上がったばかりでした。IPAさんに最初の脆弱性報告をしました。正式のものではありません。以下のような文面でした。自分で発見した脆弱性ではないこともあり、手抜きしていますし、口調がぞんざいです(恥)。失礼しました。 IPA脆弱性窓口御中 いつもお世話になっております。 私宛に匿名で(どうもproxyを使ってWebサービスの 「この商品をお友達に紹介」の伝言部分でコ

    interNet POLICE 警察庁 インターネット安全・安心相談 過去にあった脆弱性の件 - hoshikuzu | star_dust の書斎
    mi1kman
    mi1kman 2007/04/16
    直ったから再公開したのか,閉鎖は全体ではなく一部コンテンツに対するものだったのか,などいろいろ気になる.追記:どうやら間違いだったっぽい
  • 対策遅らせるHTMLエンコーディングの「神話」

    クロスサイト・スクリプティングという言葉は元々,WebアプリケーションのHTMLエンコード漏れなどを利用することによって第三者にJavaScriptを実行させる手法を指す。広義では,HTMLのエンコードによる画面改変などを含むこともある。 前回述べたように,クロスサイト・スクリプティングのぜい弱性はWebアプリケーションに見付かるぜい弱性の半分以上を占める。数年前から指摘されているにもかかわらず,一向になくならない。その理由として,クロスサイト・スクリプティング対策あるいはHTMLエンコード注1)に対する「神話」があり,正しい対策の普及を遅らせているように思う。その「神話」の数々について説明しよう。 注1)実体参照(entity reference)というのが正式だが,あまり普及していない用語なので,HTMLエンコードという用語を用いる 「すべからくHTMLエンコードすべし」が鉄則 HTM

    対策遅らせるHTMLエンコーディングの「神話」
    mi1kman
    mi1kman 2007/04/10
    文字コードを利用したXSSはブラウザの責任かウェブアプリの責任か.個人的にはブラウザが対応すべき問題だと思うんだけど.参考:http://cgi36.plala.or.jp/tera5/v/security/char_xss1/chap01.html
  • 脆弱性のユーザ自衛について思うこと

    システムの利用者がシステムを使うにあたり、基的な脆弱性がないかを調べる(+見つけたらサイト管理者に報告)という行為、はたして良いことなのか悪いことなのか? 「それは犯罪行為だ!!」、「気になるならチェックすれば?」、「絶対チェックするべきだ!」、といろんな意見があるかと思うけど、私は「利用者にもチェックする権利」はあるんじゃないかと思う。 具体的に何をしたか?、悪意があったのか?のポイントでもちろん犯罪にもなると思うけど、悪意なしでのチェック(データ書き換えたり人のデータを見たりなどをしない)+すぐに管理者への報告を行えば、悪意が無かったことは簡単に証明される(できる)と思うし、チェックをする行為は問題ないんじゃないかとやっぱり思ってしまう。 ちょっと話が変わるけれど… 以前会社で、メーリングリストを社外のASPを利用するか、社内に構築するかという話になり、 その時に「社外の管理で

    mi1kman
    mi1kman 2007/02/24
    脆弱性の影響を完全に受けないようにしたいんだろうけど,それには当該のシステムを利用しない以外にないんじゃないかな.
  • [大手企業向け]グループウェアを超える情報共有を実現するアリエル・ネットワーク

    株式会社明治 経理業務の全領域を「HUE AC」シリーズで刷新。年間54万枚の紙、2,400時間のファイリング作業を削減。

    mi1kman
    mi1kman 2007/02/18
    XSS脆弱性があった事実について,リリースノートの「解決された問題」という項目にひっそりと書いてある.プレスリリースには記述なし.対応しないよりはましだけど微妙な対応.
  • [大手企業向け]グループウェアを超える情報共有を実現するアリエル・ネットワーク

    株式会社明治 経理業務の全領域を「HUE AC」シリーズで刷新。年間54万枚の紙、2,400時間のファイリング作業を削減。

    mi1kman
    mi1kman 2007/02/18
    XSS脆弱性があった事実について,リリースノートの「解決された問題」という項目にひっそりと書いてある.プレスリリースには記述なし.対応しないよりはましだけど微妙な対応.
  • Japan Vulnerability Notes/ベンダーからの情報

    mi1kman
    mi1kman 2007/02/18
    XSS脆弱性があった事実について,リリースノートの「解決された問題」という項目にひっそりと書いてある.プレスリリースには記述なし.対応しないよりはましだけど微妙な対応.
  • potDのブックマーク / 2007年2月16日 - はてなブックマーク

    なんとなーく、脆弱性を見つける→IPAへ報告というのが一般的なのかと、何を見たわけでもなく思ってる自分がいて、報告をしたりもした。 報告したものは基的に、脆弱性がありそうだな…と思い、怪しい場所をチェックをしてやっぱり見つかったりするので報告するという感じ。 でも、その理由をそのままIPAに報告すると「脆弱性を探すのはやめなさい(やめてください)」といった旨の返事がくる。 私も割と大きめなWEBサービスの開発運営に関わっているのでこれは間違い無いと思うけれど、普通に使ってて、たまたま脆弱性が見つかるなんて結構稀なパターンじゃないかと思う。(もちろん無いわけではない) 通常、普通に使っててたまたま見つかるような部分はテストされてるからね。 となると、脆弱性は普通ではやらないような部分とかに残ってる。 自分が利用してるor利用しようと思ったWEBサービスに、致命的な脆弱性があると嫌なの

    mi1kman
    mi1kman 2007/02/16
    自衛するのは勝手だけど,ウェブサイトに脆弱性があればそれは運営者の責任であって,サービス利用者の自己責任なわけがない.
  • http://pamgau.net/item/351

    mi1kman
    mi1kman 2007/02/13
    外野には何の問題があったのかさっぱり.ユーザを全て把握できているならこのような対応でもよいのだろうか.>「ユーザ宛に送付されてきたメールにはちゃんと書いてあります。」
  • 高木浩光@自宅の日記 - 情報処理技術と刑事事件に関する共同シンポジウムで講演予定, 未届けと推定される脆弱性情報が公開されているのを発見したら

    ■ 情報処理技術と刑事事件に関する共同シンポジウムで講演予定 再来週土曜日の以下のシンポジウムで講演とパネル討論に出ます。楽しみです。 情報処理技術と刑事事件に関する共同シンポジウム 「IT技術と刑事事件を考える−Winny事件判決を契機として−」 開催日時: 平成19年2月17日(土) 10:00-17:00 開催会場: 大阪弁護士会館2階ホール [大阪市北区西天満1-12-5] 主催: 大阪弁護士会 刑事弁護委員会、情報ネットワーク法学会、情報処理学会 概要: 昨今の情報処理技術、特にインターネット等の発展により、情報処理技術や著作権法などの特別刑法が複雑に絡みあった刑事事件が数多く起こっております。このような事件の弁護活動には、当然ではありますが情報処理技術に関する素養、関連諸法規の知識、さらには技術や産業の発展といった多角的な見識が必要とされます。 そのような中で、ファイル共有ソフ

    mi1kman
    mi1kman 2007/02/04
    >「適法かどうかは自分で判断するしかなく、それが出来ない人は何もしないべきであり、出来る人だけが届け出ればよい。間口が狭いがそれはしかたのないことだ。 」
  • IPAたんからお礼が! - ぼくはまちちゃん!

    はじめてのほうこく IPAたんからの返事 IPAたんからへんじこない のつづきです!!! 返事きたよ! きてました>< Date: Thu, 01 Feb 2007 20:43:06 +0900 To: Hamachiya2 Subject: 【IPA#32334280/IPA#11631745/IPA#92669403/IPA#94436430】 届出いただいた件について - ----------------------------------------------------------------- このメールは、以下の取扱い番号に関する連絡です。 IPA#32334280/IPA#11631745/IPA#92669403/IPA#94436430 - ----------------------------------------------------------------

    IPAたんからお礼が! - ぼくはまちちゃん!
    mi1kman
    mi1kman 2007/02/04
    4について,違法な手段で入手した匿名の届出をIPAが受理すると,逆にIPAが犯罪者を守ることになる.むしろIPAは匿名の届出を受け付けるべきではなく,違法性の判断は発見者自身で行うしかない.この提言はむしろ危険.
  • IPAを甘やかすな: 国民宿舎はらぺこ 大浴場

    はまちやを甘やかすな (kyoumoeの日記30歳 さま) とりあえず、今回のケースでは、はまちや2さんは IPA という独立行政法人に、名という個人情報 (個人属性?) をあずけたくないという意思表示を示しているという点を無視するべきではないと思いますよ。例えば、警察へ通報を行う際には、必ずしも実名を名乗る必要はありません。 IPA が脆弱性の報告に際して氏名と連絡先の提示を求める根拠は、FAQ の中で説明しています。その根拠というのが中川昭一元経済産業大臣による告示な訳ですが (注: PDF ファイルです!!)、この中では、報告者が氏名を明かさねばならない理由については触れられていません。仮に、情報の信頼性を担保する為なのだとして、それが信頼しうる有効な情報であることを検証する能力が IPA に無いのだとしたら、それはそれで問題なのでは無いでしょうか? (「正確な情報」である必要は必

    mi1kman
    mi1kman 2007/02/02
    正論ではあるんだが,敷居を下げたら下げたで別の問題も出てくるんだよね.いたずらの届出ばかりになって制度が機能しなくなるのも困りもの.
  • IPAセミナー受付フォームにおけるクロスサイト・スクリプティングのぜい弱性について - 葉っぱ日記

    これの修正。 IPAと遊ぶなら、こういう瞬間的なおもしろさを求めたネタよりも、末永くお付き合いした上で見られるIPAの動向のほうがよっぽど面白いと思う。大真面目に失敗してるときもありますし。 あと、あちこち見ていて思うんだけど「IPAの、氏名必須な制度が気にわない」というのなら、この制度を利用しない(IPAには届け出ない)という選択肢を選び、それとは全く別に、制度の改善要求として匿名での報告したいということをIPAに伝えればよいと思います。 go.jp なわりには、想像以上に柔軟にいろいろ対応してくれますよ、IPA

    IPAセミナー受付フォームにおけるクロスサイト・スクリプティングのぜい弱性について - 葉っぱ日記
    mi1kman
    mi1kman 2007/02/02
    任意のガイドラインだからこそ,発見者には選択の自由がある.
  • 極楽せきゅあ日記 [セキュリティ]制度を選ぶかどうかは自由

    いやー、いろいろ騒がしい中(笑)文字通り締め切りに追われていたわけですが、何とかかんとか出来上がりましたー。ぃぁ、もちろんまだ終わってないものもあるけどね(笑)。 さて今晩もまた企画会議ということでヽ(´ー`)ノ 届け出制度は強制されるものではないし、選択は自由だと思いますね。しかし、制度を選択しないからと言って、大公開GOGO!ということをお勧めしているわけではありません。それは強引杉(笑)。というか危険じゃないのかな。 2003年11月(逮捕は翌年2月だったけど)のあの事件てのは、そもそもその「いきなり大公開」というところが問題だったわけだしね。 気がついちゃったネタがほんとに問題だと思うのなら、制度を選ばずに、かといって大公開せずに、サイト運営側に直接お知らせしてあげれば良いのではないですかね。 もちろん、制度の改善は引き続いて行われていくものですし、まだまだ現状で完璧とは思ってませ

    極楽せきゅあ日記 [セキュリティ]制度を選ぶかどうかは自由
    mi1kman
    mi1kman 2007/02/02
    脆弱性届出法のような強制力を持つものではなく,むしろ任意のガイドラインとして存在するからこそ,発見者には選択の自由が与えられている.
  • フレッシュリーダーの脆弱性に関連してSage++のこと (ひぐまのひまグ)

    実はこの連絡を受けるまで寡聞にしてJPCERT/CCという組織のことは知らなかったのですが、Wikipediaによると「コンピューターセキュリティの情報を収集し、インシデント対応の支援、コンピュータセキュリティ関連情報の発信などを行う中間法人」らしいです。 来なら早急に脆弱性の内容を確認して対策バージョンをリリースすべきだとは思うんですが、JPCERT/CCから脆弱性情報の詳細を入手するには開発者ベンダ登録リストというものに住所・氏名・電話番号等の個人情報を登録する必要があるらしく、残念ながら当方では緊急度・影響度が不明な脆弱性情報を入手することの必要性と、そのために自分自身の個人情報を晒すというリスクの度合いを比較検討した結果、これ以上の情報入手を断念しました。従いまして指摘を受けた脆弱性(具体的内容は不明)は現時点でも対策されていません。 ただ、JPCERT/CCからの連絡によるとこ

    mi1kman
    mi1kman 2007/01/24
    本家開発者ではないとはいえ,利用者のことを真に考えればこのような対応が取れるはずがない.自分のかわいさ故に利用者を危険にさらした.もしかして,JVNで個人情報が晒されると勘違いした?
  • 1