IEにURLを偽装できる脆弱性 91
ストーリー by yoosee
偽称専用ツール 部門より
偽称専用ツール 部門より
ex曰く、"デンマークのセキュリティ企業Secunia社により、IEにURLを偽装できる、パッチ未公開の脆弱性が発見された。情報としては、セキュリティホールmemoの2003年12月11日の情報がよくまとまっているだろうか。
当初は、JavaScriptを無効にすれば当面の対応ができるとされたが、実はHTMLに直接コードを書くことにより、JavaScript無効の環境でも、誰でも簡単に偽装ができてしまう。しかも、ステータスバーやプロパティにも本来の情報が表示されなくなる書き方も発見された。
マイクロソフトは、この脆弱性を「緊急度が低いもの」としており、12月の月例アップデートではパッチをリリースしないことを表明。パッチの完成度を高めてから発表するとの事。さらに、「今後は、配布スケジュールを現在の1カ月に1度から3カ月ごと、もしくは半年ごとに変更することも考えている」という。(Internetwatchの記事)
マイクロソフトのHotfixが基本的に月例アップデートになってから数ヶ月だが、このような形で対処が遅れていく事に、個人的には不安感を感じている。"
技術的な判断だけではなく社会的な影響を考慮してほし (スコア:4, すばらしい洞察)
このセキュリティホールの危険なところは、 アドレスバーに表示されたURLと 実際にアクセスしたサイトとが異なっていても SSLの「鍵マーク」が表示されることにあると私は考えます。
この脆弱性によって、 初心者が素朴に「鍵マーク」がついているから安全と考えて、 偽のサイトに対してクレジットカード番号や個人情報などの重要な情報を送信してしまうという ケースが考えられます。
たしかに、技術的な観点から見れば、 アドレスバーの表示が偽造できるというセキュリティホールは、 リモートからマシンがコントロール可能になるといったたぐいの セキュリティホールと比べて、重要度は低いかもしれません。
しかし、そのセキュリティホールが前述したような犯罪に利用される可能性がある以上、 その重要度は技術的な脆弱性と比較しても決して劣るものではありません。
ウェブブラウザ市場をマイクロソフトが事実上、独占していることを考えると、 セキュリティホールの修正に対するマイクロソフトの社会的責任は大きいといえます。 マイクロソフトは脆弱性の評価を技術的な観点のみでおこなうのではなく、 その社会的な影響を考慮したうえで評価すべきですし、 またそうしたセキュリティの修正は迅速に行なう責務があるはずです。
Re:技術的な判断だけではなく社会的な影響を考慮して (スコア:3, おもしろおかしい)
このセキュリティホールの危険なところは、リンクをポイントしたときに、 JavaScriptを無効にしていてもステータスバーに表示されるURLと実際にアク セスするサイトが異なるように偽造することができるという点にあると私は考 えます。
この脆弱性によって、初心者が「入口はこちら」をクリックしようとしたとき に、ステータスバーに表示されるURLを判断基準として利用することができな くなります。
その結果、このセキュリティホールを利用した悪意のあるサイト開設者が、有 用な情報提供をすることなしに、広告収入を得ることが可能になります。
ウェブブラウザ市場をマイクロソフトが事実上、独占していることを(以下省略)
Re:技術的な判断だけではなく社会的な影響を考慮して (スコア:0)
であれば、今回の脆弱性も、受動的攻撃でパスワードを盗まれ得るものなのですから、緊急とするのが慣例ではないでしょうか。
日
Re:技術的な判断だけではなく社会的な影響を考慮して (スコア:0)
理系?で聡明な貴方に教えていただきたいのですけど、exploit code はバッファー・オーバー・フローを利用したものに限定されるのですか?
exploit code は
Re:技術的な判断だけではなく社会的な影響を考慮して (スコア:1)
元コメント [srad.jp]の方は、
“バッファオーバーフロー(をはじめとしたバイナリ形式で攻撃コードが動作する、デモプログラムの公開=攻撃コードの公開とならない脆弱性)じゃないっての。 ということなんだが、この東貴彦という人はexploit code の意味わかってる?”
と言いたいのでは。
違います?
(まあ悪意がある物、改変が容易に可能な物に限らず、ソースが公開されていないデモプログラムもそりゃ確かに"exploit code"なのだが……)
Mozilla でも発生 (スコア:2, 参考になる)
Re:Mozilla でも発生 (スコア:5, 参考になる)
中身はセキュリティホールmemo12/11 [ryukoku.ac.jp]の焼き直しですが。
※なにげにSafariはクリアしているのですね・・・
- Ryuzi Kambe -
Re:Mozilla でも発生 (スコア:1)
Re:Mozilla でも発生 (スコア:0)
「簡単な例」がわかりづらいです(笑)
# 最初、何事が起こったのか?とジッとアドレス欄を見てしまった。
Re:Mozilla でも発生 (スコア:2, 参考になる)
Gekko(moziila、Firebird)→ポイント時は偽装される、プロパティでは表示される
Opera→表示される
KHTML(KDE、Safari)→表示される
各々最新版においてはこんな感じだと思われます。
はてなの方に少し書いて [hatena.ne.jp]みました。
もっともポイント時のurlをみないでぽんぽん押してしまってはあまり意味はありませんが…。
Re:Mozilla でも発生 (スコア:1)
JavaScript版の場合、Gekko→ポイント時もプロパティも偽装可能となります
(セキュリティホールmemoのテストページにて確認)
adblock(Re:Mozilla でも発生) (スコア:2, 参考になる)
Adblock 0.5 d2 nightly 30で試したところ、ルールに"*%01@*"を加え、"Site Blocking"にチェックすることでブロックできました。
GETのクエリー部にこれが含まれてた場合どうなるかは試してません。
# これからsquidの設定もやらないと...
Re:Mozilla でも発生 (スコア:2, 参考になる)
var l = _window.document.links;
for (var i = 0; i < l.length; i++)
l[i].href = l[i].href.split("%00").join(".localhost.localdomain/");
# 「ページ読み込み時に自動で実行する」にチェックを入れてください。
参考リンク:鎌田氏の解説 [nifty.com]
本題とは直接関係ないですが… (スコア:2, 参考になる)
(既知なのかどうか調べる気もおきず、ひっそりと)
裏技? (スコア:2)
自分も「裏技レベル」だと思う (スコア:1, 参考になる)
http://d.hatena.ne.jp/hoshikuzu/20031210#p7 [hatena.ne.jp]
スクリプトもActiveXも不要だし、書くのも簡単だし、偽朝日も偽創価学会も偽りそなも偽アマゾンも作り放題だよなぁ...
MSは (スコア:1)
例えば
修正プログラム提供の偽メールをランダムに送付
→偽サイトにアクセスさせる
→ユーザがダウンロードしたものは実は(略)
とか。
バグ≠脆弱性 (スコア:1)
とりあえず、CNETの解説 [cnet.com]でもよく読んどく。
# ACなのでAC
Re:裏技? (スコア:0)
インプレスでは数年前から実用化してます (スコア:2, おもしろおかしい)
PC うおっち 2003年版 [impress.co.jp] PC うおっち 2002年版 [impress.co.jp]
PC うおっち 2001年版 [impress.co.jp] PC うおっち 2000年版 [impress.co.jp]
なお、PC うおっち 1999年版 [impress.co.jp]以前は偽装工作はしてないみたいです。
Re:インプレスでは数年前から実用化してます (スコア:1)
今回の場合の肝はスクリプトオンでも偽装可能だって事であって。
アドレス確認ボタン (スコア:2, 参考になる)
実際に表示されているURIをポップアップで表示するものみたいですね。
Referer偽造 (スコア:2, 参考になる)
今時Refererの先頭文字列が自分のドメインだからどんな
リクエストも受け付けるってなサーバーサイドプログラム
はないよね?ね?
Refererの存在を仮定してはいけない (スコア:1, 参考になる)
する、というのは以前はよく見た手法ですね。 BBS の CGIが
外部からのプログラム的な連続投稿を禁止させるために、とか。
(今ならセッションクッキーを使うのが一般的かと)
ただ、「プロキシでRefererを削っているケースがあるから」と
いう現状から導いた理由ではなくて、HTTP のお約束のなかで
HTTP クライアントは Referer の送信を制御できるようにすべき
だと書いてありますから Refererが必ず存在すると仮定しては
いけないと思いますよ。
RFC 2616 の 15.1.2 Transfer of Sensitive Information ですね。
http://www.ietf.org/rfc/rfc2616.txt
http://www.studyinghttp.net/rfc_ja/2616/sec15.html#sec15.1.2
Typo自己申告 (スコア:1)
「艤装」じゃなくて「偽装」です。
_| ̄|○
不安を感じている? (スコア:1, おもしろおかしい)
Re:不安を感じている? (スコア:0)
お前が感じている感j(略
META Refresh も偽装に利用 (スコア:1, 参考になる)
content="0;URL=http://www.yahoo.com@www.yahho.com/"
だとアドレス欄には http://www.yahoo.com と表示されるのに
実際には www.yahho.com にアクセスしてる。
ユーザの URLタイプミスと絡めるとなんかストーリーが出来そう。
偽Google (スコア:1, 興味深い)
月例化した結果 (スコア:0)
>>「今後は、配布スケジュールを現在の1カ月に1度から3カ月ごと、もしくは半年ごとに変更することも考えている」
再び放置プレイに戻りそうなこと言われると困るんだけどなぁ。
Re:月例化した結果 (スコア:2, おもしろおかしい)
2.だんだん緊急が多くなって、週刊化
3.頻度に苦情が多くなってまとめる方向に
4.1にもどる。
気の持ちよう (スコア:1, すばらしい洞察)
もう第三のブラウザに乗り換えるしかないかも (スコア:1)
個人的にはKDE [kde.org]デスクトップ向けのブラウザKonquerorもしくはSafariをWindowsにも移植して欲しいです。
Super Souya
Re:月例化した結果 (スコア:0)
巨大になってしまい、発行時には企業のネットワーク
回線がパンクするでしょう。 家庭ユーザもそれなりに
大変でしょうね。
で、「ネットワーク帯域を圧迫しないようCDによる配布を
行う」という計画が立ち上がり「それってサービスパックと
なにが違うの?」という話に...
Re:月例化した結果 (スコア:1)
してもらった方がありがたい気がする。そうしたら、
「Windows XP Ver.3.11 か。そろそろ安定した頃だから採用しようか」
とかいう判断もできるのに。
Re:月例化した結果 (スコア:1)
Re:月例化した結果 (スコア:0)
Re:月例化した結果 (スコア:0)
パッチがリリースされるタイミングに関わらず、
当てないやつは当てないって事さ。
< ブラスター系のウイルスも減ってない
Re:月例化した結果 (スコア:0)
1週間待てばなんらかの報告が会ったのに
最近のはアップデータのバグ修正が1ヶ月後に判明して出すってのはちょっとなめすぎ
#CDの交換サービスを行った方がいい気がする。
#インストールし直してもてもパッチしなくて済むので、それがバグってたら終わりですけど
Re:月例化した結果 (スコア:0)
緊急に必要と思われるパッチを1ケ月以上先に出されてもねぇ...
ウィルスやワーム等が流行った後ですって話になる(苦笑)
Re:月例化した結果 (スコア:1)
ホームユース限定だけど・・。
艤装 (スコア:0)
>
> ex曰く、"デンマークのセキュリティ企業Secunia社により、
> IEにURLを艤装できる、パッチ未公開の脆弱性が発見された。
難しい漢字なので調べてみました
ぎそう
(名)スル
船体が完成して進水した船に就航に必要な装備を施すこと。また、その装備。船装。
有料化の前兆か? (スコア:0)
Re:有料化の前兆か? (スコア:0)
疑うのは自由ですがね。
Re:有料化の前兆か? (スコア:1)
CD-ROMでの配布は有償(年間購読とか...)って事ならむしろやって欲しい位ですがね。
Re:有料化の前兆か? (スコア:0)
興味本意で始めたユーザーなんて「使ってないのに金払うのは勿体ない」で
雑に扱われ次第にその程度のOSに成り下がってしまう
結局壊れるまで一度もアップデートされない状態で壊れたら即捨てられるでしょう。
Re:IEですか? (スコア:1)
しかも、IE5系までしか動いてくれないので、困ってます。
今月で延長サポートフェイズ終わりだ…IE5.5SP2…
今月の月例アップデートが無いってことは、もうパッチでないってことですかーMSさんー。
Re:IEですか? (スコア:1)
具体的にはIE5.01SP3もしくは5.01SP4へ移行。
2000環境の場合、これらのサポートはまだ続きますから。
しかし、その労力がかなり苦しいのですけどね。
しかし、これらのサポートは続けるってのは、要するにMSはIEとOSは一体だって示したいわけですよねえ…
Re:IEですが。 (スコア:1, 参考になる)
でもOutlookに影響するウイルスメールが‥という触れ込みでも実際に
影響こうむっていた多数派はその他の各種メール、という某所での
オチを知ってるだけに他のブラウザでも安心は禁物だったりする。
(大丈夫と安心しきった油断が一番狙い目なのでね、派生攻撃は)
#んなもんで、応用パターンが既に幾つも出てきているからそれに合わせた
#フィルタ作成が面倒この上ないったらありゃしない。
Re: (スコア:1)
ものだと思いますが、続きが知りたいです。
Flashでも同じことをやってみたということでしょうか。
Flashプラグインを介したときに、ユーザ変数を含むURLに移動しようとした場合のOperaや、この脆弱性にたいする修正が入ったMozillaの挙動は確かに気になりますね。
- Ryuzi Kambe -