Microsoft、Google Chromeのパッチ提供方針を批判 32
ストーリー by headless
更新 部門より
更新 部門より
Microsoftが9月に発見したGoogle Chromeの脆弱性を例に、Googleのパッチ提供方針を批判している(Windows Security blogの記事、
The Vergeの記事、
Neowinの記事、
The Registerの記事)。
CVE-2017-5121はChromeのV8 JavaScriptエンジンで境界外メモリーアクセスが可能になるというもの。MicrosoftはGoogleのProject Zeroチームがよく使用するFuzzingという手法で脆弱性を検出し、リモートからのコード実行が可能になることも確認したとのこと。
GoogleはMicrosoftから9月14日に脆弱性の通知を受け、9月21日に安定版をリリースしたChrome 61.0.3163.100で修正している。ただし、この脆弱性に関するバグトラッカーは一般公開されていないが、修正がGitHubでコミットされたのは9月18日。Microsoftはコードの修正部分は修正版の一般提供後に公開すべきだと主張する。
本件ではバグの修正内容から直接脆弱性を知ることはできなず、修正版が一般提供開始されるまでの期間も短い。しかしMicrosoftによれば、Chromeでは修正がコミットされてから1か月近くたって修正版の一般提供が開始されたものもあるという。
MicrosoftではMicrosoft EdgeのJavaScriptエンジン「Chakra」のコア部分を「ChakraCore」としてオープンソース化しているが、修正版の提供を開始するまではリポジトリの更新を行わないとのことだ。
CVE-2017-5121はChromeのV8 JavaScriptエンジンで境界外メモリーアクセスが可能になるというもの。MicrosoftはGoogleのProject Zeroチームがよく使用するFuzzingという手法で脆弱性を検出し、リモートからのコード実行が可能になることも確認したとのこと。
GoogleはMicrosoftから9月14日に脆弱性の通知を受け、9月21日に安定版をリリースしたChrome 61.0.3163.100で修正している。ただし、この脆弱性に関するバグトラッカーは一般公開されていないが、修正がGitHubでコミットされたのは9月18日。Microsoftはコードの修正部分は修正版の一般提供後に公開すべきだと主張する。
本件ではバグの修正内容から直接脆弱性を知ることはできなず、修正版が一般提供開始されるまでの期間も短い。しかしMicrosoftによれば、Chromeでは修正がコミットされてから1か月近くたって修正版の一般提供が開始されたものもあるという。
MicrosoftではMicrosoft EdgeのJavaScriptエンジン「Chakra」のコア部分を「ChakraCore」としてオープンソース化しているが、修正版の提供を開始するまではリポジトリの更新を行わないとのことだ。
だれもソースを読んでないな (スコア:3, 参考になる)
Windows Security Blogの該当ポスト [microsoft.com]を読め。
ブラウザ10画面以上にわたる長文記事の大半は技術的な解説で、Googleの対応を批判しているのは最後から2つ目の2段落のみ。
Googleが報告からわずか4日後に修正してきたことや、Microsoftに7,500ドルの報奨金を支払ったことも紹介しているし、
最終段落では、「考え方は違うが、我々はユーザーを守るために協力できると確信している」とも述べている。
わざわざここだけ取り上げるメディアもいただけない。
批判の内容としてはGithubへの公開が早すぎるというもので、例えば、バグトラッカーでは非公開扱いされている
security issueの修正が、Githubにテストコード付きで公開されているようなケースがあるとのこと。
これは攻撃者に脆弱性を攻撃する時間的余裕を与えてしまう。
Chromeの場合はChromiumとの関係があるから少し難しいが、
一般論としては議論の余地もないような当然の話で、著名なソフトウェアでは、
セキュリティフィックスは別のブランチで管理して、製品リリースと同時に公開すべきだ。
例えばWPA2の脆弱性の時も、Linuxは脆弱性公開までfixを非公開にしていた。
Re:ゼロから始まる王様ゲーム (スコア:0)
バグ情報の公開方法はいつも利害を分かち合う双方でバトっているなぁ
内野に近い外野からしてみれば、そんなことはどーでもいいから
さっさとパッチんぐ！さっさとパッチんぐ！しばくぞ！
Re: (スコア:0)
おまゆうバトルだよねぇ。。
黙って仕事しろ、と。
Re:ゼロから始まる王様ゲーム (スコア:1)
いや、黙ってしまってはダメだ論争が必要な分野だよ。
Re: (スコア:0)
話し合いとか論争とかを勧める人は多いけど、双方に結論を出す意思がないとタダの小田原評定だからなそれ。
選挙制度も多数決も、話し合いで決着つかないから行われる制度だと理解してない人が多い。
Re: (スコア:0)
双方に結論を出す意思がないと
これなあ・・・。
自分の主張を一部(あるいは全部)曲げる結末を受け入れる心構えがないと、低レベルな言い合いから進展しないんだよな、ほとんど。
Re: (スコア:0)
何故、この件の二社だけの話し合いと思い込んだのかは不明だけど。
双方に結論を求める事だけが議論の効果ではない。
それを見た第三者がどうするか決める切っ掛けになれば良いよ。
バージョン管理システムとリリースとの関係 (スコア:0)
オープンソースで悩ましい問題の1つではありますね。
ソースコードの修正履歴としてセキュリティホールの修正が含まれうる以上、
バージョン管理システムのリポジトリを先に更新してしまうと、
悪意のある(が知識のそれほど無い)ユーザが気付いて攻撃を始める、という
Microsoftの主張もわからんではないです。
ただし、ソースコードを事前に公開せずにコンパイル済みのバイナリのみを提供すると仮定すると、
一般公開前のテストの際、何がどう直っているのかを確認することが
できなくなってしまいます。かといって、テスターだけに修正ソースコードを公開するというのも、
それはそれでオープンソースの原則に反してしまい、実質的なNDA (機密保持契約)になってしまいます。
本来論でいうならば (スコア:1)
コミットしていないソースのバイナリを正式版として展開するのはおかしい。
なのでGoogleの行為自体には全く問題がない。
Microsoftが攻撃の材料としているために議論を脱線させているように感じるが、
主張すべきなのはコミットタイミングではなく公開タイミングではないのだろうか？
であるならばコミットと同時に広く公開されるのではなく
一部のコミット内容については、限定的または時限的に公開される枠組みを志向するべきだろう。
Re: (スコア:0)
同時公開で済む話だろ、
コミット云々にしたって、公開用のリポジトリと別でリポジトリでいいだろうが。
まっとうなSCMだとブランチ機能あるんだから出来るだろ。
脆弱性ゆえに修正版を出すまでに情報を秘匿する必要がある場合に事前をソースを公開してたら本末転倒ってのは正しいぞ。
Re: (スコア:0)
一部のコミット内容については、限定的または時限的に公開される枠組みを志向するべきだろう。
そんなものは真のオープンソースではないとかそんなようなことを言い出す人もいるだろう。
共同開発のためにソースコードを公開しているのに一部とはいえ非公開にすると色々面倒くさいし。
そもそも論で言えばパッチを配布すればそれを解析する連中がいるので脆弱性のみを修正するパッチを単独で配布するのは危険だな。パッチが広く行き渡るまでに時間がかかることを考えるとパッチの提供後当面ソースコードを非公開のままにせにゃならんし。
何を言いたいのか自分でもわからなくなってきた。俺は「ソフトウェアの公開は危険だからやめろ」と言いたいのか？
Re: (スコア:0)
オープンソースの原則に反しないだろ
GPLでもソースを公開する相手は配布したバイナリを持っている相手だけでいいわけで
Re: (スコア:0)
クロームやクロミウムは広く無償公開されているので修正済みのバイナリだけ配布するとソースコードの開示を利用の条件とするライセンスと矛盾してしまう。あといわゆる第三者のレポジトリのバイナリをどうするのかという問題もあるし。主要なディストリビューターに対してのみ公開しディストリビューター側の準備ができた段階で公開する手はあるがじゃあ主要なディストリビューターをどう選ぶのかという問題があるね。漏れたディストリビューターのバイナリは結局危険ってことになる。
これが外部から呼び出すためのライブラリの場合でも同じような問題が生じる。
まあChromeはグーグルが管理しているからいいのだがLinuxなんかだと厄介なことになる。
#バイナリだけ公開するとライセンス上アレソースコードだけ先に公開すると安全性上アレ同時公開は実務上アレ
Re: (スコア:0)
Chromiumはマルチライセンスなのでバイナリだけ公開しようが矛盾しません
Re: (スコア:0)
Googleは公開優先
MSは安全性優先
と言えるかな。
でもWPA2みたいなので前者のスタイルやられたらシャレにならん。。
Re: (スコア:0)
そういえば関連リンクにあるけどGoogleって連絡受けてから一週間以内にパッチかアドバイザリー出さないとダメってポリシーだったっけ
WPA2のやつは対応遅れてたけど今もそのポリシーって残ってるのかな
Re: (スコア:0)
あれははMSを叩くための方便ですので、自社には適用されません。
Re: (スコア:0)
パッチは未提供でも脆弱性情報はちゃんと公開されている。だから矛盾はない。ってスタンスかも。
Re: (スコア:0)
たしかに、WPA2では発表日と公開日を
同日にしようという提案があったのに
Microsoftは先行して配布を行ない
Linux系OSは同日配布を行ない
Macはまだ配布をしていない。
どう見ても一番悪いのはM(日記はここで途切れている)
Re: (スコア:0)
ソースだけ公開するのはやめろという話なんだが。
Re: (スコア:0)
バイナリを公開する前にソースだけ公開すんなだな
Gitのリポジトリだと修正箇所がdiffで大変わかりやすく示されるから
そこから脆弱性発覚→バイナリ公開までの期間に攻撃される
常に脆弱性を狙われてたMSからすりゃ、あり得ないって考えるのは至極当然
Re: (スコア:0)
#バイナリだけ公開するとライセンス上アレソースコードだけ先に公開すると安全性上アレ同時公開は実務上アレ
Re: (スコア:0)
実務上アレってなに? 説明できないんだ。
ソースコードのバージョン管理とリリース管理は別物ですよ。
Googleは手を抜いているだけ。
Re: (スコア:0)
実務上のあれ＝無能ゆえに対応出来ない or 面倒くさい
Re: (スコア:0)
説明、面倒くさいときは、「キャンセル」押すけどな
Re: (スコア:0)
過去の版を使っている人にまで最新のソースを開示できてなきゃいかんの？
Re: (スコア:0)
まあ、リリースまでの間だから...
たぶん、
1.機能拡張とかのリリースとは別にセキュリテイリリースがあるようなリリースマネジメントにする(一緒くたに出すことはしない)
2.セキュリティリリースのブランチは非公開でrcテスト
3.リリース後にmasterなどにマージ&ブランチ公開
みたいな管理をコアチームというかリリース管理チーム&セキュリティ保守でちゃんとやるしかないんだろうなあ...
chromeはすくなくとも、chromiumへの反映はリリース後にできるようにがんばれなくはないはず、chromium+Googleのプロプラ部分で厳密には=じゃないんだし
ただ、どこまでこれ(とか)が通るのかってのはあるだろうなあ
M-FalconSky (暑いか寒い)
Re: (スコア:0)
全然反してないでしょ？
「オープンソースの原則」なんて、公開したものに対応するコードが付属していりゃいいんだから
公開する前の段階でどういう手順で開発してテストするかなんて開発するやつが好き勝手に決めることじゃん
別にコミットしてレビューしてパッチ採用してってプロセスを全部公開でやる義務はない
セキュリティーチームでもなんでも作ってひっそりやればいいだけのこと
Re: (スコア:0)
そもそも製品が出荷されて半年ぐらい経って忘れた頃に公開するメーカーとかも珍しくないしな
（昔のLinux採用ガラスマのメーカーとか）
Androidだと (スコア:2)
AOSPでとっくにソースが公開されてるのに、
2、3ヶ月もかかって自社製品のファームウェアに取り込んで公開する始末ですよ。
ちょっと古い製品だと、それすらもしない。
Nexus はなくなっちゃったし、Pixel は日本に来る気配すらないので、
セキュリティ上まともに使えるのって Android One くらいじゃないかな？
しかし、それすらアップデートの保証は発売後2年間という無様な体たらくですけど。
uxi
Re: (スコア:0)
半年間誰もソース要求しなかったんじゃないのw
無題 (スコア:0)
マイクロソフト、グーグル。
どっちもどっちだろう。
お互いに蹴り合いなんて醜い。