Microsoft、Google Chromeのパッチ提供方針を批判 20
ストーリー 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」としてオープンソース化しているが、修正版の提供を開始するまではリポジトリの更新を行わないとのことだ。
Re:ゼロから始まる王様ゲーム (スコア:0)
バグ情報の公開方法はいつも利害を分かち合う双方でバトっているなぁ
内野に近い外野からしてみれば、そんなことはどーでもいいから
さっさとパッチんぐ!さっさとパッチんぐ!しばくぞ!
Re: (スコア:0)
おまゆうバトルだよねぇ。。
黙って仕事しろ、と。
Re: (スコア:0)
いや、黙ってしまってはダメだ論争が必要な分野だよ。
Re: (スコア:0)
話し合いとか論争とかを勧める人は多いけど、双方に結論を出す意思がないとタダの小田原評定だからなそれ。
選挙制度も多数決も、話し合いで決着つかないから行われる制度だと理解してない人が多い。
Re: (スコア:0)
双方に結論を出す意思がないと
これなあ・・・。
自分の主張を一部(あるいは全部)曲げる結末を受け入れる心構えがないと、低レベルな言い合いから進展しないんだよな、ほとんど。
バージョン管理システムとリリースとの関係 (スコア:0)
オープンソースで悩ましい問題の1つではありますね。
ソースコードの修正履歴としてセキュリティホールの修正が含まれうる以上、
バージョン管理システムのリポジトリを先に更新してしまうと、
悪意のある(が知識のそれほど無い)ユーザが気付いて攻撃を始める、という
Microsoftの主張もわからんではないです。
ただし、ソースコードを事前に公開せずにコンパイル済みのバイナリのみを提供すると仮定すると、
一般公開前のテストの際、何がどう直っているのかを確認することが
できなくなってしまいます。かといって、テスターだけに修正ソースコードを公開するというのも、
それはそれでオープンソースの原則に反してしまい、実質的なNDA (機密保持契約)になってしまいます。
Re:バージョン管理システムとリリースとの関係 (スコア:1)
まあ、リリースまでの間だから...
たぶん、
1.機能拡張とかのリリースとは別にセキュリテイリリースがあるようなリリースマネジメントにする(一緒くたに出すことはしない)
2.セキュリティリリースのブランチは非公開でrcテスト
3.リリース後にmasterなどにマージ&ブランチ公開
みたいな管理をコアチームというかリリース管理チーム&セキュリティ保守でちゃんとやるしかないんだろうなあ...
chromeはすくなくとも、chromiumへの反映はリリース後にできるようにがんばれなくはないはず、chromium+Googleのプロプラ部分で厳密には=じゃないんだし
ただ、どこまでこれ(とか)が通るのかってのはあるだろうなあ
M-FalconSky (暑いか寒い)
本来論でいうならば (スコア:1)
コミットしていないソースのバイナリを正式版として展開するのはおかしい。
なのでGoogleの行為自体には全く問題がない。
Microsoftが攻撃の材料としているために議論を脱線させているように感じるが、
主張すべきなのはコミットタイミングではなく公開タイミングではないのだろうか?
であるならばコミットと同時に広く公開されるのではなく
一部のコミット内容については、限定的または時限的に公開される枠組みを志向するべきだろう。
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)
バイナリを公開する前にソースだけ公開すんなだな
Gitのリポジトリだと修正箇所がdiffで大変わかりやすく示されるから
そこから脆弱性発覚→バイナリ公開までの期間に攻撃される
常に脆弱性を狙われてたMSからすりゃ、あり得ないって考えるのは至極当然
Re: (スコア:0)
#バイナリだけ公開するとライセンス上アレソースコードだけ先に公開すると安全性上アレ同時公開は実務上アレ
Re: (スコア:0)
過去の版を使っている人にまで最新のソースを開示できてなきゃいかんの?
Re: (スコア:0)
全然反してないでしょ?
「オープンソースの原則」なんて、公開したものに対応するコードが付属していりゃいいんだから
公開する前の段階でどういう手順で開発してテストするかなんて開発するやつが好き勝手に決めることじゃん
別にコミットしてレビューしてパッチ採用してってプロセスを全部公開でやる義務はない
セキュリティーチームでもなんでも作ってひっそりやればいいだけのこと
Re: (スコア:0)
そもそも製品が出荷されて半年ぐらい経って忘れた頃に公開するメーカーとかも珍しくないしな
(昔のLinux採用ガラスマのメーカーとか)