AppleとGoogleが修正し、Microsoftが修正しなかった脆弱性とは 47
ストーリー by headless
仕様 部門より
仕様 部門より
Microsoftはセキュリティ脆弱性として報告されたバグをセキュリティ脆弱性ではないなどの理由で修正しないこともあるが、AppleやGoogleが3月に修正したのに対し、Microsoftだけが修正しなかったという脆弱性をCiscoのTalosグループが公表した(Talosのブログ記事、
TALOS-2017-0306、
The Registerの記事)。
脆弱性はApple SafariやGoogle Chrome、Microsoft Edgeでコンテンツセキュリティポリシー(CSP)のバイパスが可能になるというもの。攻撃の流れとしてはContent-Security-Policy HTTPヘッダーで「'unsafe-inline'」を有効にし、「window.open()」で空のドキュメント(about:blank)を開く。新しいドキュメントは元のドキュメントと同一生成元だが、CSPが無効化されるため、「document.write」関数でコードを書き込めば同一生成元ポリシーを無視して他のWebサイトからデータを読み取ることができる。
Talosでは脆弱性を発見後、2016年11月29日にMicrosoftに通知したが、Microsoftは今年3月に仕様であり、脆弱性ではないと回答。Talosは再考を促したものの、修正の予定はないとの回答を受けて9月6日に脆弱性を公表した。一方、AppleはiOS 10.3およびSafari 10.1で修正済み(CVE-2017-2419)、GoogleもChrome 57.0.2987.98で修正済み(CVE-2017-5033)だ。'unsafe-inline'によるインラインスクリプトの有効化が問題とする見方もあるが、どのような場合でもクロスサイトアクセスはブロックすべきであるとTalosは主張する。なお、Mozilla Firefoxでは新しいドキュメントが元のドキュメントからCSPを継承するため、同様の問題は発生しなかったとのことだ。
脆弱性はApple SafariやGoogle Chrome、Microsoft Edgeでコンテンツセキュリティポリシー(CSP)のバイパスが可能になるというもの。攻撃の流れとしてはContent-Security-Policy HTTPヘッダーで「'unsafe-inline'」を有効にし、「window.open()」で空のドキュメント(about:blank)を開く。新しいドキュメントは元のドキュメントと同一生成元だが、CSPが無効化されるため、「document.write」関数でコードを書き込めば同一生成元ポリシーを無視して他のWebサイトからデータを読み取ることができる。
Talosでは脆弱性を発見後、2016年11月29日にMicrosoftに通知したが、Microsoftは今年3月に仕様であり、脆弱性ではないと回答。Talosは再考を促したものの、修正の予定はないとの回答を受けて9月6日に脆弱性を公表した。一方、AppleはiOS 10.3およびSafari 10.1で修正済み(CVE-2017-2419)、GoogleもChrome 57.0.2987.98で修正済み(CVE-2017-5033)だ。'unsafe-inline'によるインラインスクリプトの有効化が問題とする見方もあるが、どのような場合でもクロスサイトアクセスはブロックすべきであるとTalosは主張する。なお、Mozilla Firefoxでは新しいドキュメントが元のドキュメントからCSPを継承するため、同様の問題は発生しなかったとのことだ。
そもそも 'unsafe-inline' は危険なので使うべきではないとW3C勧告に書かれている (スコア:3)
CSP を導入しているけど、インラインスクリプトが使えないと不便だからか 'unsafe-inline' を許可しているサイトも多いですが、危険だし、中途半端で美しくないポリシーだと思います。
6. Content Security Policy Directives [w3.org] より
'unsafe-inline' は XSS 攻撃を可能にするので、いずれのケースであっても、指定すべきでない (SHOULD NOT) とされており、（危険なため）'unsafe-inline' や 'data:' は完全に避けるのが最善（they are best avoided completely）とも書かれています。
# 一応補足しておくと、nonce を使って 'unsafe-inline' の安全性を高める方法も W3C 勧告に書かれています
そもそも、CSP を導入する主目的は、エスケープ漏れで XSS (インジェクション系の脆弱性) があった場合に、注入された不正なスクリプトが実行されるのを防ぐためだと思います。'unsafe-inline' という SHOULD NOT な指定をしてしまうと、XSS 脆弱性があったときに不正なインラインスクリプトが実行されてしまう恐れがあり、その時点で手遅れとなります。
仮に他のポリシーで form の post 先のオリジンを限定していたとしても、例えば Cookie に含まれるセッションIDを盗みたい場合には、同一オリジンにブログのコメント欄があったらそこに post して盗み取るとか、お問い合わせフォームを悪用（差出人を攻撃者のメールアドレスにして、問い合わせ内容にセッションIDを含めフォームを送信し、送られてくる控えからセッションIDを盗むなど）するなど、あらゆる方法で悪用できてしまいます。
そういう問題ではない (スコア:1)
被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア:3, 参考になる)
headless さんは、加害者のサイト http://bad.example.com/ [example.com] のWebサーバ に「Content-Security-Policy: 'unsafe-inline';」を指定して、http://bad.example.com/ 上の JavaScript コードで about:blank を開き、about:blank に注入した JavaScript コードから 被害者のサイト http://good.example.com/ [example.com] にアクセスする方法で脆弱性を利用するのだと、誤解しているように思えます。
TALOS-2017-0306 - Cisco Talos [talosintelligence.com] の Details を読んでみましたが、実際に XSS 脆弱性を悪用して情報を盗み取る方法までは書かれておらず、シンプルに CSP 制限を迂回できることを脆弱性として指摘しているだけでした。
しかし、実際にこの脆弱性を悪用する方法としては、被害者のサイトに「Content-Security-Policy: 'unsafe-inline';」が指定されている必要があります。
参考までに TALOS-2017-0306 - Cisco Talos [talosintelligence.com] の Details を和訳してみました。
Details なのに説明がシンプルすぎて逆に分かりにくいので、再現手順を例示すると、
と、これだけ。
本来、CSP 制限により http://example.com/ [example.com] から http://example.jp/ [example.jp] の画像にアクセスできないはずだけど、http://example.com/ から開いた about:blank からは http://example.jp/ [example.jp] にアクセスできてしまったという脆弱性です。
これを実際に悪用する場合、アクセスするユーザーが脆弱性のあるブラウザ（Microsoft Edge）を使っているだけでなく、
の2つの条件を満たしている必要があります。
CSP が正常に機能していれば、XSS脆弱性を悪用されて悪意のあるコードが埋め込まれたとしても、その悪意のあるコードからクロスドメインアクセスはできないはずだけど、Edge の脆弱性を使ったらそれができてしまうという内容です。
Re:被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア:1)
Re:被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア:2)
Blog [talosintelligence.com] も読みました。
"There are three main components to an exploitation attempt:" の段落については、あくまでも脆弱性を再現する手段の記述であって、実際に悪用するための方法ではないので、'unsafe-inline' をセットするのが攻撃者なのか被害者なのかは特に記述されていませんし、脆弱性の再現は 'unsafe-inline' をセットするのが誰であっても可能です。
しかし、攻撃者が自分で管理している bad.example.com のHTTPヘッダーに "unsafe-inline" をセットして、そこから window.open() で about:blank を開いたとして、回避できるのはあくまでも bad.example.com に対する CSP の制限だけです。
実際に何らかの悪用をするためには、"unsafe-inline" がセットされている good.example.com に XSS脆弱性でスクリプトをインライン埋め込みし、good.example.com に対する CSP の制限を回避する必要があります。
ブログの文章にも "in order to bypass CSP restrictions put on the document." とはっきり書かれてます。the document の the は、定冠詞であって、この場合 document を今話題にしている document に限定することを意味するのであって、任意のオリジン（任意のドメイン名）の document に対する制限をバイパスできるわけではありません。CSP の制約を回避できるのは、元の document (window.open のコードを埋め込んだ CSP が設定されたオリジンのdocument) に対してのみです。
CSP による制限と、ブラウザ標準の Same-Origin Policy (同一オリジンポリシー) との違いについては、#3277045 [srad.jp] に書きました。
Re:被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア:1)
Re: (スコア:0)
言葉遊びやる前に、事実を無視して一方的にMSを悪者に仕立て上げる内容になってるストーリーの内容を修正したほうがいいと思うけどねぇ
運営（しかもストーリー採用者）なんだから個人よりもまずスラド全体のことを考えてください
それとも事実無根の話でMS叩くことがスラドにおける至上命題なのですか？
Re: (スコア:0)
エクスプロイトの手順としては攻撃対象も攻撃者が用意するってだけのような
CSPは未設定の状態が一番緩くてこの脆弱性自体が「CSPの制約を回避する」って物なのだから
実際の攻撃シナリオとしては標的になったサイトのunsafe-inlineを回避して未設定にする以外ありえないです
あと同一生成元ポリシーはCSPの設定有無に関わらず適用される話でCSPに何を設定しても緩くはなりません
(CSPは外部リソースを取り込む側、同一生成元ポリシーは取り込まれる側で制限したり許可したりする物です)
Re: (スコア:0)
CSPをセットすると基本的に未設定のときよりも制約が厳しくなるだけなので、
攻撃者が自分のサイトにCSPをセットする意味がないように思います。
何もなければsame-origin policyだけなのでリクエスト送信も、
レスポンスのプラウザ主体での利用も制限されないはずです。
ブログ記事の攻撃手順ってこのストーリーの2段落目に対応するざっくりした説明のことですよね？
「An attacker may be able to bypass the policy specified by the Content-Security-Policy header, causing an information leak. 」
(攻撃者はCSPによる制限を回避して情報を流出させることが出来る)ってなってますし、回避対象が制御下に有るわけが
Re:被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア:1)
Re:被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア:2)
「There are three main components to an exploitation attempt: ～略～」の段落については、あくまでも脆弱性の検証をするための実証方法・実証コードを示しているに過ぎません。
「攻撃者が何らかの方法で'unsafe-inline'をセットすると読む」のではなく「脆弱性の再現検証を行う際には、検証者が 'unsafe-inline'をセットする（あるいは 'unsafe-inline' がセットされている環境を使用する）」と読むべきです。
こう書くと、「exploitation attempt」の日本語訳は「悪用しようとする試み」なのだから「攻撃手段」だと反論されそうですが、「exploitation」は「exploit」の名詞系です。「exploit」という言葉は、情報セキュリティ分野での専門用語でして、エクスプロイトのWikipedia [wikipedia.org] を見れば分かるように「セキュリティ確認目的での、脆弱性検証するための実証コード(Proof of concept：PoC)を指すこともある。」（Wikipediaより引用）とされています。ブログに書いてあるのは「攻撃手順」というより「脆弱性の再現検証のための手順」です。
当該脆弱性を実際に悪用するクラッカーが「何らかの方法で'unsafe-inline'をセットする」のは、合理的ではありません。攻撃者が「何らかの方法」例えばWebサーバの脆弱性を利用してHTTPヘッダーを操作できるのであるならば、何もそんなことをしなくても「Content-Security-Policy」を削除すれば CSP は完全に回避できるわけで、この脆弱性を利用する必要性は全くありません。
Re: (スコア:0)
#3276994 に書かれてることも理解できないのにMSを悪者にしようと必死にならなくてもいいよ
運営なんだからしっかりしようよ、間違いは認めなよ
それもできないでMS叩きしようと固執するのが今のスラドなの？
Re: (スコア:0)
最終的にCSPを回避できるという脆弱性なのですでにCSPか解除(未設定)されてるところにCSPを設定して攻撃する前提は成立しないし、
そもそも「何らかの方法」でCSP設定を好きに変更できる脆弱性があるならいっそ解除してしまえば良いわけでやはり脆弱性として成立しない。
脆弱性を結果から順に辿れば間違えようがないだろこんなの・・・
・CSPの迂回が可能という脆弱性
・CSPの迂回が発生するのはブランクウィンドウ内のコード
・ブランクウィンドウ生成とその中のコードをスクリプトで生成する
・生成するスクリプトはインラインで実行される
・unsafe-inlineがセットされた状況である
・脆弱性の前提としてXSSが関係している
サイト一つとブランクウィンドウしか出てこなくて、CSPの迂回が目的でCSPがセットされているのはそのサイト。
つーかさ、普段は誤字脱字をさらっと修正しててhylomより遥かに優秀な感じなのになんでこのストーリーだけこんな馬鹿晒してんの？
Re:被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア:1)
Re: (スコア:0)
つまりheadlessさんは一次情報のTalos detailsよりも
単なるまとめサイトみたいなメディアThe Registerを信用して
まんまと誤解したということね。
CSPとかセキュリティの基礎知識がないと、仕方ないね。
exploitは（というか英語はなんでもそうだけど）動詞にも名詞にも使いますね。
だいたいは冠詞でわかるのでは?
I lookとTake a lookみたいに。
ていうか反論するとこ、そこなの？
もうスラドはheadlessさん一人でもっている状態なんだから、
見苦しい言い訳はやめて、今後のいい記事につなげてくださいよ。
Re: (スコア:0)
新iPhoneの直前でMSやGoogleをなんとしても叩くようApple陣営の方から依頼されてるんだろうね
Re:被害者のサイトに CSP 'unsafe-inline' の指定が必要 (スコア:1)
Re: (スコア:0)
落とした表現でっていうなら
『「'unsafe-inline'」を有効にし、』
→『「'unsafe-inline'」を有効な状態で、』
とするほうが良いのでは。
あと、
『新しいドキュメントは元のドキュメントと同一生成元だが、CSPが無効化されるため』
→『新しいドキュメントはCSPが無効化されるため』
『同一生成元ポリシーを無視して他のWebサイトからデータを読み取ることができる。 』
→『CSPを無視して他のWebサイトへデータを含んだリクエストを送ることができる。 』
とでもしときましょうよ。
Re:そういう問題ではない (スコア:1)
攻撃者が自分のサイトに設置するんなら最初からCSP自体設定しなければいいのでは。
今回の話は'unsafe-inline'な設定の標的サイトに対して、攻撃者がXSSな投稿を行い、
それをEdgeで踏んだ場合に、親コメントに有るような小細工無しで
「window.open()
→document.write()
→CSP未設定なabout:blank経由で任意のサイトへアクセス
→CSRFまたはXSSにより取られたデータの外部送信」
が発生するって脆弱性だと思うのですが。
Re:そういう問題ではない (スコア:1)
Re:そういう問題ではない (スコア:2)
headless さんの解釈だと、攻撃者が、攻撃者の管理するサイトの CSP に 'unsafe-inline' を指定し、そこから about:blank を開くことで、ブラウザ標準の Same-Origin Policy (同一オリジンポリシー) を回避して、異なるオリジンのリソースとやり取りし放題になる脆弱性だということでしょうか？
もし、そうだとしたら、例えば任意のドメイン名のWebサイトからCookieを盗めることになり、世界中が大騒ぎになってますよ。
の2つを勘違いされているようです。今回の問題はあくまでも後者です。
その根拠は、TALOS-2017-0306 - Cisco Talos [talosintelligence.com] の下記の記述
異なるオリジンへのネットワークアクセスの仕様 [mozilla.org] を理解していれば分かりますが、ブラウザ標準の Same-Origin Policy (同一オリジンポリシー) では、別のオリジンからの画像の読み込みはブロックされません。それがブロックされると書かれているので、あくまでも Content Security Policy (CSP) による制限の話です。
Re: (スコア:0)
同一生成元ポリシーで別オリジンと判定されてもリクエストを飛ばす類の事は大体問題なく許可されます。
CORSで利用を許可する方法からしてレスポンスからヘッダを確認とかなので、リクエストは飛んでしまいます。
CORSで許可されないと無理なのは取得した内容の利用や操作だけでブラウザ上の表示とかは普通に行われます。
なのでXSSした標的のサイトから取ったデータを攻撃者が管理するサーバに送るのに制限はありませんし、
Access-Control-Allow-Originをつければ次の操作指示を流し込むことも出来ます。
CSRFを行う場合はCSRF先の防御状態に依存するのでなんともいえませんけ
Re: (スコア:0)
#3277042 の内容は、もう 'unsafe-inline' を使うかどうかと関係ない話になってるので
その領域まで行ってしまった推測はほぼ確実に間違った解釈だろうと言える
また、このコメの流れを見ればわかる通り、 headless 自体が今回の脆弱性の内容を正しく理解できていない
誤った脆弱性情報を流すことはまさにそれ自体が社会の迷惑以外の何物でもないので
可能であればいったんストーリー自体を取り下げるか、大幅修正するべきだろう
そもそもなぜそんな曖昧な認識のまま、
あたかもMSが悪かのようなタイトルで記事を掲載してしまったのか
スラドそのものの体制から見直すべきいい機会だと思う
Re: (スコア:0)
#3277042は#3277037のコメントに対する返信なのでCSP未設定の場合の話であってますよ。
headless氏の誤解を前提とすると矛盾が生じるって話なので。
> あたかもMSが悪かのようなタイトルで記事を掲載してしまったのか
確かにheadless氏は攻撃手順を誤解してはいるようですが、
'unsafe-inline'なCSP制限下で制限を回避できてしまうのは事実ですし、
#3276913の内容を見ると分かるようにCSP3(のnon-normativeな項目)ではCSPは継承するべきとされるようです。
CSP2では該当箇所が見当たらないのでCSP2ではリーガルな挙動であり、
MSはCSP3のnon-normativeな項目にはまだ対応して
Re: (スコア:0)
今回の件でいえば、 headless 氏が
「すべての外部サイトに対して攻撃者が好きに攻撃し放題の重大脆弱性なんだ、それをMSだけ修正しないんだ」
と一人で勘違いした結果、
ストーリーのタイトルや文面がMSに対して強い攻撃性を持った内容になっていることが重大な問題
もっと言えばタイミングも最悪で、9/12の某林檎イベントの直前となっている
イベントの前に何が何でもMSを叩きたいという思考が暴走した結果の勘違い（または意図的なフェイクニュース）と思われても仕方がない
Re: (スコア:0)
Edgeで初期状態で有効なポップアップブロックをわざわざ無効にして攻撃者のサイトにアクセスし、
さらにほとんどのブラウザやアンチマルウェアソフトウェアで搭載されるようになったサイトチェックも無効にしていて、
さらに攻撃者の狙った通りに攻撃コードが機能するサイトを他に開いていて、
挙句に（サイトチェックではなく、ローカル監視としての）アンチマルウェアソフトウェアが攻撃コードを検知せずに実行を許可したとき、
もしかしたら成立するかもしれないね
そうだね、もうHTTPなんて使うなよ
「危険なので使うべきではない」と書かれているから危険な目にあっても仕方がない？ (スコア:0)
Microsoftが修正しないことの理由にはなっていませんね。
Re: (スコア:0)
> Microsoftが修正しないことの理由にはなっていませんね。
いいえ、まさにここがMSが修正しないという選択肢をとることのできる理由そのものです
Re: (スコア:0)
それで、今まで動いてたシステムが動かなくなったら文句言うんだろ？
そもそも危険だ、それを知って実装するならそれなりに注意を払うべきだ。という大前提をすっ飛ばしてこうすれば動くといってプログラム書くやつが多すぎるからこうなるんだ。
Re: (スコア:0)
M$のIEやEdgeのみサポートなんてサイトは、その程度のエンジニアが作成した地雷原だと思って、近づかないようにしましょうということですよ。
Re: (スコア:0)
自分の頭に向けて銃を撃つ奴のためだけにそれだけを防ぐ安全装置を付けろなんて言う馬鹿はいない
これはいいだろ (スコア:1)
これで文句言う暇があるならPHPの「仕様です」に文句言ってくれ
Re: (スコア:0)
「お察しください。」
Re: (スコア:0)
PHPの仕様はPHPが勝手に決められるけど(標準化されてるわけでもないし)、CSPの仕様はMicrosoftが決めてるわけじゃないだろ。
Re:これはいいだろ (スコア:1)
そっすね。記事がわかりにくいけど、よく読むと最後の一文が重要みたいですね。
CVE-2017-5033 [mitre.org]から辿って
https://bugs.chromium.org/p/chromium/issues/detail?id=669086 [chromium.org]
からさらに
https://w3c.github.io/webappsec-csp/#initialize-document-csp [github.io]
まで行くとわかる。about:がCSPを継承しないのはバグ。
Re: (スコア:0)
それはあなたがPHPの仕様を気に食わないと思ってるだけなんじゃ…。
MSを悪者にしたい意図はよくわかったが (スコア:1)
「バグではなく仕様です」なんてのはAppleもGoogleもさんざん振りかざしてきたことだし、
AppleやGoogleも含めて標準仕様に完全準拠しているものでもない
というより今のMSと比べるとAppleやGoogleのほうが勝手に標準仕様を拡張して変えてくのが大好きなところだからね
逆にMSは過去との互換性を確保するために「バグではなく仕様です」を使うことが多いところ
また、
> 'unsafe-inline'によるインラインスクリプトの有効化が問題とする見方もあるが、
> どのような場合でもクロスサイトアクセスはブロックすべきであるとTalosは主張する
とあるとおり、そもそも今回の話は一方的にMSが悪いというものですらない
Re:MSを悪者にしたい意図はよくわかったが (スコア:1)
今のHTMLの方針はベンダーがガンガン実装して仕様確定は後からというスタイルなので、
ブラウザベンダに対して「標準仕様に完全準拠しているものでもない」とか
「勝手に標準仕様を拡張して変えてくのが大好き」というのはナンセンス。
今回MSが悪いわけではないという点と、メジャーなブラウザベンダの中で今のMSが保守的というか大人しいという点には同意。
Re: (スコア:0)
'unsafe-inline'は攻撃者の都合で設定できるんじゃないの？
Re: (スコア:0)
中間攻撃者がいる前提ではそもそもHTTP使ってる時点で何やっても無駄
HTTPSを使えば改ざんされないからまともなサイト（unsafe-inlineをそもそも使わない）なら問題ない
つまるところ攻撃される前提ならunsafe-inlineを使わないことが重要で、
それをあえて使うような性善説社内イントラシステムとかではMSの対処のほうが過去互換性などの面でメリットとなる点がある
だから今回の件でMSを攻撃している人はほとんどいない
アンチMSが必死に大声で暴れているだけ
Re: (スコア:0)
仕様的に存在認めちゃってる問題と、ブラウザの立ち位置の問題かなぁ。
セキュリティ的には不安要素排除優先で使えなくしても良いと思うけど、ブラウザの使われ方がなぁ。。。
Re: (スコア:0)
Edgeがw3の仕様に違反してるのは事実なので、直さないと決めた理由がわからないんだけど、なんか理由があるんだろうね。CSPを継承したらマズい場所が他にあるんだわ。
Re: (スコア:0)
明確に継承すべきって書いてあるのはCSP3みたいだけど、そもそもEdgeってCSP3に準拠しているの？
検索したら CSP2をサポートしたよ。今後はCSP3やってくよ [microsoft.com]みたいな記事が出てきたけどCSP3全体をサポートしたとは書いてなさ気。
そもそもCSP3はまだドラフトっぽいし・・・CSP2でも継承必須なんだろうか？
> CSPを継承したらマズい場所が他にあるんだわ。
単に変更箇所が大きいってだけのような気もします。
ウ
え？ (スコア:0)
2000年ごろには
about:でコード書き出し放題って
MSに報告済みですが何か
# JS叩けるとか何を今更
Re: (スコア:0)
そいつぁすげえや。
ところで2000年にCSPは無かったよ。