パスワードを忘れた? アカウント作成
13436400 story
Chromium

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」としてオープンソース化しているが、修正版の提供を開始するまではリポジトリの更新を行わないとのことだ。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2017年10月22日 14時39分 (#3299838)

    Windows Security Blogの該当ポスト [microsoft.com]を読め。

    ブラウザ10画面以上にわたる長文記事の大半は技術的な解説で、Googleの対応を批判しているのは最後から2つ目の2段落のみ。
    Googleが報告からわずか4日後に修正してきたことや、Microsoftに7,500ドルの報奨金を支払ったことも紹介しているし、
    最終段落では、「考え方は違うが、我々はユーザーを守るために協力できると確信している」とも述べている。
    わざわざここだけ取り上げるメディアもいただけない。

    批判の内容としてはGithubへの公開が早すぎるというもので、例えば、バグトラッカーでは非公開扱いされている
    security issueの修正が、Githubにテストコード付きで公開されているようなケースがあるとのこと。
    これは攻撃者に脆弱性を攻撃する時間的余裕を与えてしまう。

    Chromeの場合はChromiumとの関係があるから少し難しいが、
    一般論としては議論の余地もないような当然の話で、著名なソフトウェアでは、
    セキュリティフィックスは別のブランチで管理して、製品リリースと同時に公開すべきだ。
    例えばWPA2の脆弱性の時も、Linuxは脆弱性公開までfixを非公開にしていた。

  • by Anonymous Coward on 2017年10月21日 14時28分 (#3299493)

    バグ情報の公開方法はいつも利害を分かち合う双方でバトっているなぁ
    内野に近い外野からしてみれば、そんなことはどーでもいいから
    さっさとパッチんぐ!さっさとパッチんぐ!しばくぞ!

    • by Anonymous Coward

      おまゆうバトルだよねぇ。。
      黙って仕事しろ、と。

      • by Anonymous Coward on 2017年10月21日 16時08分 (#3299528)

        いや、黙ってしまってはダメだ論争が必要な分野だよ。

        親コメント
        • by Anonymous Coward

          話し合いとか論争とかを勧める人は多いけど、双方に結論を出す意思がないとタダの小田原評定だからなそれ。

          選挙制度も多数決も、話し合いで決着つかないから行われる制度だと理解してない人が多い。

          • by Anonymous Coward

            双方に結論を出す意思がないと

            これなあ・・・。
            自分の主張を一部(あるいは全部)曲げる結末を受け入れる心構えがないと、低レベルな言い合いから進展しないんだよな、ほとんど。

          • by Anonymous Coward

            何故、この件の二社だけの話し合いと思い込んだのかは不明だけど。
            双方に結論を求める事だけが議論の効果ではない。
            それを見た第三者がどうするか決める切っ掛けになれば良いよ。

  • by Anonymous Coward on 2017年10月21日 14時49分 (#3299505)

    オープンソースで悩ましい問題の1つではありますね。

    ソースコードの修正履歴としてセキュリティホールの修正が含まれうる以上、
    バージョン管理システムのリポジトリを先に更新してしまうと、
    悪意のある(が知識のそれほど無い)ユーザが気付いて攻撃を始める、という
    Microsoftの主張もわからんではないです。

    ただし、ソースコードを事前に公開せずにコンパイル済みのバイナリのみを提供すると仮定すると、
    一般公開前のテストの際、何がどう直っているのかを確認することが
    できなくなってしまいます。かといって、テスターだけに修正ソースコードを公開するというのも、
    それはそれでオープンソースの原則に反してしまい、実質的なNDA (機密保持契約)になってしまいます。

    • by Anonymous Coward on 2017年10月21日 17時29分 (#3299563)

      コミットしていないソースのバイナリを正式版として展開するのはおかしい。
      なのでGoogleの行為自体には全く問題がない。

      Microsoftが攻撃の材料としているために議論を脱線させているように感じるが、
      主張すべきなのはコミットタイミングではなく公開タイミングではないのだろうか?

      であるならばコミットと同時に広く公開されるのではなく
      一部のコミット内容については、限定的または時限的に公開される枠組みを志向するべきだろう。

      親コメント
      • by Anonymous Coward

        同時公開で済む話だろ、
        コミット云々にしたって、公開用のリポジトリと別でリポジトリでいいだろうが。
        まっとうなSCMだとブランチ機能あるんだから出来るだろ。
        脆弱性ゆえに修正版を出すまでに情報を秘匿する必要がある場合に事前をソースを公開してたら本末転倒ってのは正しいぞ。

      • by Anonymous Coward

        一部のコミット内容については、限定的または時限的に公開される枠組みを志向するべきだろう。

        そんなものは真のオープンソースではないとかそんなようなことを言い出す人もいるだろう。
        共同開発のためにソースコードを公開しているのに一部とはいえ非公開にすると色々面倒くさいし。
        そもそも論で言えばパッチを配布すればそれを解析する連中がいるので脆弱性のみを修正するパッチを単独で配布するのは危険だな。パッチが広く行き渡るまでに時間がかかることを考えるとパッチの提供後当面ソースコードを非公開のままにせにゃならんし。
        何を言いたいのか自分でもわからなくなってきた。俺は「ソフトウェアの公開は危険だからやめろ」と言いたいのか?

    • by Anonymous Coward

      オープンソースの原則に反しないだろ
      GPLでもソースを公開する相手は配布したバイナリを持っている相手だけでいいわけで

      • by Anonymous Coward

        クロームやクロミウムは広く無償公開されているので修正済みのバイナリだけ配布するとソースコードの開示を利用の条件とするライセンスと矛盾してしまう。あといわゆる第三者のレポジトリのバイナリをどうするのかという問題もあるし。主要なディストリビューターに対してのみ公開しディストリビューター側の準備ができた段階で公開する手はあるがじゃあ主要なディストリビューターをどう選ぶのかという問題があるね。漏れたディストリビューターのバイナリは結局危険ってことになる。
        これが外部から呼び出すためのライブラリの場合でも同じような問題が生じる。
        まあChromeはグーグルが管理しているからいいのだがLinuxなんかだと厄介なことになる。
        #バイナリだけ公開するとライセンス上アレソースコードだけ先に公開すると安全性上アレ同時公開は実務上アレ

        • by Anonymous Coward

          Chromiumはマルチライセンスなのでバイナリだけ公開しようが矛盾しません

          • by Anonymous Coward

            Googleは公開優先
            MSは安全性優先

            と言えるかな。
            でもWPA2みたいなので前者のスタイルやられたらシャレにならん。。

            • by Anonymous Coward

              そういえば関連リンクにあるけどGoogleって連絡受けてから一週間以内にパッチかアドバイザリー出さないとダメってポリシーだったっけ
              WPA2のやつは対応遅れてたけど今もそのポリシーって残ってるのかな

              • by Anonymous Coward

                あれははMSを叩くための方便ですので、自社には適用されません。

              • by Anonymous Coward

                パッチは未提供でも脆弱性情報はちゃんと公開されている。だから矛盾はない。ってスタンスかも。

            • by Anonymous Coward

              たしかに、WPA2では発表日と公開日を
              同日にしようという提案があったのに

              Microsoftは先行して配布を行ない
              Linux系OSは同日配布を行ない
              Macはまだ配布をしていない。

              どう見ても一番悪いのはM(日記はここで途切れている)

        • by Anonymous Coward

          ソースだけ公開するのはやめろという話なんだが。

          • by Anonymous Coward

            バイナリを公開する前にソースだけ公開すんなだな
            Gitのリポジトリだと修正箇所がdiffで大変わかりやすく示されるから
            そこから脆弱性発覚→バイナリ公開までの期間に攻撃される
            常に脆弱性を狙われてたMSからすりゃ、あり得ないって考えるのは至極当然

          • by Anonymous Coward

            #バイナリだけ公開するとライセンス上アレソースコードだけ先に公開すると安全性上アレ同時公開は実務上アレ

            • by Anonymous Coward

              実務上アレってなに? 説明できないんだ。

              ソースコードのバージョン管理とリリース管理は別物ですよ。
              Googleは手を抜いているだけ。

              • by Anonymous Coward

                実務上のあれ=無能ゆえに対応出来ない or 面倒くさい

              • by Anonymous Coward

                説明、面倒くさいときは、「キャンセル」押すけどな

        • by Anonymous Coward

          過去の版を使っている人にまで最新のソースを開示できてなきゃいかんの?

    • まあ、リリースまでの間だから...

      たぶん、
      1.機能拡張とかのリリースとは別にセキュリテイリリースがあるようなリリースマネジメントにする(一緒くたに出すことはしない)
      2.セキュリティリリースのブランチは非公開でrcテスト
      3.リリース後にmasterなどにマージ&ブランチ公開
      みたいな管理をコアチームというかリリース管理チーム&セキュリティ保守でちゃんとやるしかないんだろうなあ...

      chromeはすくなくとも、chromiumへの反映はリリース後にできるようにがんばれなくはないはず、chromium+Googleのプロプラ部分で厳密には=じゃないんだし

      ただ、どこまでこれ(とか)が通るのかってのはあるだろうなあ

      --
      M-FalconSky (暑いか寒い)
    • by Anonymous Coward

      全然反してないでしょ?
      「オープンソースの原則」なんて、公開したものに対応するコードが付属していりゃいいんだから

      公開する前の段階でどういう手順で開発してテストするかなんて開発するやつが好き勝手に決めることじゃん
      別にコミットしてレビューしてパッチ採用してってプロセスを全部公開でやる義務はない
      セキュリティーチームでもなんでも作ってひっそりやればいいだけのこと

      • by Anonymous Coward

        そもそも製品が出荷されて半年ぐらい経って忘れた頃に公開するメーカーとかも珍しくないしな
        (昔のLinux採用ガラスマのメーカーとか)

        • by uxi (5376) on 2017年10月23日 13時08分 (#3300183)

          AOSPでとっくにソースが公開されてるのに、
          2、3ヶ月もかかって自社製品のファームウェアに取り込んで公開する始末ですよ。
          ちょっと古い製品だと、それすらもしない。

          Nexus はなくなっちゃったし、Pixel は日本に来る気配すらないので、
          セキュリティ上まともに使えるのって Android One くらいじゃないかな?
          しかし、それすらアップデートの保証は発売後2年間という無様な体たらくですけど。

          --
          uxi
          親コメント
        • by Anonymous Coward

          半年間誰もソース要求しなかったんじゃないのw

  • by Anonymous Coward on 2017年11月16日 13時10分 (#3313372)

    マイクロソフト、グーグル。
    どっちもどっちだろう。
    お互いに蹴り合いなんて醜い。

typodupeerror

Stableって古いって意味だっけ? -- Debian初級

読み込み中...