<前の日記(2005年04月14日) 次の日記(2005年04月24日)> 最新 編集

高木浩光@自宅の日記

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

2005年04月23日

他社製品は「欠陥」と報道、自社のことは「不具合」とぼかす朝日新聞社

14日の朝日新聞朝刊に「ウィンドウズ、欠陥8件公表 ウイルス侵入の危険」という見出しの記事が出ていた。ネット版では「OSなどに欠陥 MSが修正版ダウンロード呼びかけ」という見出しになっている。こうし た記事が一般紙に出るようになったことは、今ではもう珍しくない。

ところが、22日、朝日新聞社からの告知として次の見出しの発表がなされた。

  • 文字拡大・音声ツール「WebUD(ウェブ・ユーディー)」の不具合に関するお知らせ, 朝日新聞社, 2005年4月22日

    「WebUD」において、画面を開いた際にブラウザ上で自動実行される部品に不具合があることが明らかになりました。

    「WebUD」の利用者を狙った悪意あるサイトにアクセスした場合、悪意あるプログラムを実行される恐れがあります。これにより、利用者のPC内のファイルが読み取られたり、書き換えられる可能性があります。

なぜ欠陥ではなく、脆弱性でもなく、不具合なのか。

これはJVN#A7DA6818 の件のようだ。私はこの件の発見者(届出者)ではないので、どのような 脆弱性なのか詳細は知らないが、製造者である富士通の発表文の「対応方法」 には、ActiveXコントロールを削除するようにと指示されていることから、 おそらく、インターネットゾーンで呼び出されると危険な機能を持つActiveX コントロールであるにもかかわらず、「スクリプトを実行しても安全」とマー クして出荷していたということではなかろうか*1

朝日新聞社の告知によれば、「悪意あるプログラムを実行される」とあり、 「ファイルを書き換えられる」ともあるので、任意コードの実行が可能となっ ていた可能性*2がある。であれ ば、それによってもたらされる脅威は、ウイルスやスパイウェアの埋め込みな どが挙げられるべきところだ。

Windowsの脆弱性を伝える記事にあった表現

最も重大な「緊急」と位置づけており、(略)

今回見つかった欠陥を放置した場合、コンピューターウイルスが入り込みやす くなったり、ハッカーからパソコン内部の画像ファイルを消される攻撃を受け たりする恐れがあるという。

OSなどに欠陥 MSが修正版ダウンロード呼びかけ, 朝日新聞, 2005年4月13日

は、そのまま「文字拡大・音声ツール」にも当てはまる表現だろう。たとえば、 今回の件を新聞記事風に次のように書くことができる。

朝日新聞社は22日、同社のウェブサイト「asahi.com」で配布していたパソ コン用ソフト「WebUD(ウェブ・ユーディー)」に欠陥が見つかったと公表し た。最も重大な「緊急」と位置づけており、同社のホームページを通じて、 組み込んだソフトと部品を削除するよう、また「信頼された発行元」から 「FUJITSU LIMITED」を削除するよう呼びかけている。

今回見つかった欠陥を放置した場合、コンピューターウイルスが入り込みやす くなったり、ハッカーからパソコン内部のファイルを書き換えられる攻撃を受 けたりする恐れがあるという。

にもかかわらず、Microsoftの件は「欠陥」で、自分のところの告知は 「不具合」なのか。

「不具合」という表現の選択にはどのような意図が込められているだろうか。たとえば、14日に発表されたJVN#9ADCBB12のケースを見てみる。ここには、

この問題は、KDDI 株式会社の端末について報告されました。製品開発者の判断により脆弱性ではないとされていますが、対策情報が公開されています。JVN では製品開発者との調整の上、ユーザへの周知を目的として、この問題を掲載しています。

JVN#9ADCBB12: 携帯電話端末における特定 QR コードを使用したサイト接続時の問題

と書かれている。こちらの発見者(届出者)は私なので問題点の詳細を知って いる。詳細については BUGTRAQ-JPで以下のように公表した。

この事象の場合、これを「脆弱性ではない」と言い、「不具合である」と言う、 その気持ちは察することができる。auの発表文では次のように説明されている。

〈事象〉
読込んだバーコードによっては、カーソルのあたっている次の行のURLにジャンプする事があります。
※尚、auホームページで公開しておりますau仕様に基づいて作成された バーコードでは本事象は発生しません。

バーコード (2次元コード) リーダーご利用にあたっての注意点, auからのお知らせ, 2005年4月14日

つまり、「au仕様に基づかないコードを読み取ると、ジャンプ先が1行ずれた ものになってしまうことがある」という説明のしかたになっている。たしかに このように表現されると、「不具合」という言葉でも似合うように感じられる*3。 「ときどき1行ずれちゃうんです」というわけだ。

たしかに、偶発的に一行ずれるようなバグであれば、それは「不具合」と呼ば れても違和感を感じない。しかし、JVN#9ADCBB12の 事象は偶発的に発生するというよりも、ほとんどの場合、攻撃者が意図して作 成したデータによって起こされるであろうし、それは 100パーセントの再現性 をもって起こされるものだ。そして、攻撃者のその意図は、ユーザのセキュリ ティを損ねるものである。

一般的な不具合ないし欠陥と、脆弱性とをなぜ区別して表現するべきかという と、ユーザがそれを修正するパッチを適用する必要があることについて、もし くは、回避策をとる必要があることについて、その必要性を正しく認識できる ようにするためだ。

偶発的に稀に起きる事象とか、特定の機能が正常に動かないといった不具合で あれば、パッチを適用しないで済ますということもあり得るが、外部からの意 図的な攻撃によって生ずる事象であれば、攻撃する者がいないうちは何も起き ないが、ひとたび攻撃が始まると確実に被害に遭うといったことになるため、 早めにパッチを適用しないといけない。もしくは、回避策があるなら問題点を 理解して避けるように行動しないといけない。そういう性質の問題点なのかど うかがすぐに見分けられるよう、脆弱性という言葉が使われるべきである。 「vulnerability」(脆弱性)は「攻撃誘発性」とも訳される。

auのバーコードリーダーBREWアプリの件では、それを「欠陥」とまで呼ぶのは 相応しくないように思う。なぜなら、このBREWアプリは、「MEBKM:」形式のデー タを読み取ると、タイトル行とジャンプ先URL行の両方をリンクにするわけだ が、これは仕様だったのだと思われる。タイトルにURLが書けることも仕様だ と見るのが自然だ。

HTMLメールでも、ハイパーリンクの表示文字列にURLを書く(リンク先とは別 の)ことができるが、たとえそれがフィッシング詐欺に悪用されまくっていて も、それは仕様だ。そういった仕様のままで受け入れられているのは、PCの Webブラウザでは、ジャンプした後でアドレスバーを見て現在地を確認するこ とができるし、本来それをするべきということになっているからだ。auのバー コードリーダの挙動も、HTMLメールのハイパーリンクと違いない。だが、携帯 電話のWebブラウザにはアドレスバーがないため、PCとは状況が異なってくる。 リンクの表示文字列に任意の文字列を指定できるHTMLのようなことは、できな いようにしておくべきなのだ。

つまり、auの件は、欠陥ではなく仕様通りの挙動なのだが、その仕様がフィッ シング詐欺という攻撃を誘発しかねないという点で、改善した方がよいと人々 のコンセンサスが得られそうな話だったからこそ、auは修正をしたわけである。 そうしたセキュリティ上の理由で改善した方がよいものを、「脆弱性」と呼ぶ。

マイクロソフト社が、脆弱性のことを欠陥と呼ばないで欲しいというようなこ とを主張しているのを、いろいろなところで耳にした。たしかに、auのバーコー ドリーダの事例に見られるように、すべての脆弱性が欠陥と呼べるものという わけではないのだから、一律に「脆弱性」を「欠陥」に置き換えて呼ぶのはよ ろしくないかもしれない。

ベンダーの立場として「欠陥」と呼んで欲しくないとする理由として、製造者 の中では「欠陥」=「瑕疵」を意味するということがどうもあるらしい。 「瑕疵」とは広辞苑によれば「〔法〕行為・物・権利などに本来あるべき要件 や性質が欠けていること」とある。マイクロソフトが「欠陥」という言葉を避 けるわりに、「脆弱性」という言葉は積極的に使っているのは、「脆弱性」と いう言葉に、瑕疵といった意味を持たせていないためであろう。

つまり、「脆弱性」とは、必ずしも製造者の瑕疵によるものだとは認めないが、 お客様のセキュリティのために改善した方がよいと判断したので、修正パッチ を提供してさしあげますよ、という性質のものではないだろうか。責任を認め ずにバンバン修正パッチをリリースできるので、「脆弱性」とはまことに便利 な言葉である。

にもかかわらず、auがバーコードリーダの件を「脆弱性ではない」としたとい うのは、まことに不可解である。「仕様通りの挙動だが、セキュリティ上よく ない仕様だったので、改善することにした」という意味で「脆弱性」と言えば よいはずだ。修正版を出すにあたって、脆弱性と認めたくないがために、修正 理由を「1行ずれることがある」という事象として捉えざるをえず、そうする とそれは仕様通りに動作しないという意味となり、「不具合」ということになっ てしまう。

私の理解では、「脆弱性」を出してしまうことより「不具合」を出すことの方 がみっともないことだと感じる。バーコードリーダの挙動は仕様通りだったの だから、不具合なんかじゃない*4

「脆弱性ではないからパッチを出さない」とか、「脆弱性ではないから発表し ない」というのならわかるが、auは、修正版も出したし、きちんとした告知も しているのだから、「脆弱性ではない」と拘ることの auにとってのメリット がわからない。それほどまでに「脆弱性」という言葉に悪いイメージを抱いて いるということなのだろうか。

脆弱性には深刻なものから軽微なものまであることをまず理解するべきだろう。 「ユーザは脆弱性と耳にしただけで恐れおののいてしまうのではないか」と心 配なのなら、脆弱性の深刻度について記述して発表すればよかろう。

話を戻すと、マイクロソフトは「欠陥」報道に不満があるようだが、少なくと も深刻度が最高レベルのものについては「欠陥」と呼んで差し支えないはずだ。 「欠陥」とは一般的な言葉であり、必ずしも法的な「瑕疵」を意味するわけで はない。

このように言葉を整理してみても、Windowsの脆弱性のときは「欠陥」と報道 している朝日新聞社が、自社の件では「不具合」と表現するのは正当性を欠く と言える。脆弱性の深刻度が最高レベルのものだからだ。深刻度を見出しに含 めずに「脆弱性」と表現するのならそれはそれでよいが、そうともしないで、 欠陥という言葉を避けるのには正当な理由が見当たらない。

もっとも、この「不具合」という表現は、製品開発者である富士通の発表文が そうなっていたため、そのまま写しただけなのだろう。

富士通は、http://software.fujitsu.com/jp/security/というセキュリティ脆弱性情報専門のページを設けており、 これまで、他社製品であろうが自社製品であろうが「脆弱性」と表現してきて いる。 たとえば以下の見出しのページがある。(「Interstage」は富士通の製品。)

ここは富士通のセキュリティ専門部隊が書いているところなので、当然の表現だ。

ところがどういうわけか、「WebUD」についてだけは「不具合」と称している。 それはプロフェッショナルとしてどうなのか? 「[緊急]」とマークまでして いるのに、あくまでも不具合なのか。

4月22日 [緊急]
「ウェブ・アクセシビリティ支援ツール「WebUD」の不具合への対応について」が公開されました。

大元の発表文は、富士通の「コンサルティング事業本部」というところが出し ているらしい。コンサルティング事業というのが何のコンサルか知らないが、 セキュリティのコンサルをする資格がないことだけはわかる。

そこが「不具合」という言葉を使えと指示したのだろうか? そんな指示に従っ て適切なアドバイスをしないセキュリティ部隊なんてのも信用に値しない。

音声読み上げブラウザにおけるphishing詐欺対策は?

何度も書いてきたとおり、フィッシング詐欺対策の要は、アドレスバーのURL を確認することであり、錠前アイコンを確認することであり、SSLの証明書異 常を示す警告が出たら「いいえ」を押すことだ。

では、WebUDのような音声読み上げブラウザにおいて、視覚障害者の使用を想 定した場合にはどうだろうか。

WebUDをざっと使ってみたところ、アドレスバーを読み上げる機能はないよう だ。全部のURLを読む必要はなくドメイン名だけでもよいので、読み上げる機 能があるべきではなかろうか。

そうした機能がないと、音声だけを頼りに使っているユーザは、自分が今どこ を見ているかについて、ページコンテンツに書かれている文章だけを頼りに信 じてしまうことになる。これは危ないのではないか。

錠前アイコンを音声で確認する機能も欲しいところだ。

というか、それ以前に、WebUDには錠前アイコン表示機能(視覚的な)からして存在しないのだが……。 IPAに脆弱性として届出ようかとも考えたが、脆弱性ではないと言われそうな ので、ここに書いてしまおう。

*1 別の可能性として、 長大な引数を与えるとバッファオーバーフロー脆弱性が発現するといったこと も考えられるが。

*2 たとえばもし、「悪意あるプログラムを実行」の意味が、 既存のコマンドの引数なし呼び出しであり、かつ、「ファイルを書き換えられ る」の意味が、特定のデータへの書き換えしかできないという場合であるなら ば、任意コードは実行できないので、あくまでも可能性。

*3 auは、この件を不具合とも言っていないが。

*4 auは、不具合とも書いていないが。

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

高木先生の日記から引用する。 http://takagi-hiromitsu.jp/diary/20050423.html#p02 何度も書いてきたとおり、フィッシング詐欺対策の要は、アドレスバーのURL を確認することであり、錠前アイコンを確認することであり、SSLの証明書異常を 示す警告が出たら「いいえ」..

検索

<前の日記(2005年04月14日) 次の日記(2005年04月24日)> 最新 編集

最近のタイトル

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|
<前の日記(2005年04月14日) 次の日記(2005年04月24日)> 最新 編集