Chrome、WebPのヒープバッファオーバーフロー脆弱性を修正

 (chromereleases.googleblog.com)
1 ポイント 投稿者 GN⁺ 2023-09-13 | 1件のコメント | WhatsAppで共有
  • デスクトップ版 Chrome の Stable および Extended Stable チャネル向けアップデートが、WebP のヒープバッファオーバーフロー脆弱性の修正を含んで配布された
  • 新しいビルドは Mac・Linux で 116.0.5845.187、Windows で 116.0.5845.187/.188 となっており、数日から数週間にわたって順次適用される
  • 今回のリリースに含まれるセキュリティ修正は 1 件で、CVE-2023-4863 は Critical に分類されている
  • Apple SEAR と University of Toronto Munk School の The Citizen Lab が、2023 年 9 月 6 日にこの脆弱性を報告した
  • Google は 実際の悪用事例 が存在すると明らかにしており、修正版が適用されるまではバグの詳細情報へのアクセスが制限される可能性がある

デスクトップ Chrome チャネルのアップデート

  • Stable および Extended Stable チャネルが、デスクトップ向けの新しいビルドに更新された
  • プラットフォーム別の Stable チャネルのバージョンは次のとおり
    • Mac: 116.0.5845.187
    • Linux: 116.0.5845.187
    • Windows: 116.0.5845.187/.188
  • Extended Stable チャネルも別バージョンで配布される
    • Windows: 116.0.5845.188
    • Mac: 116.0.5845.187
  • アップデートは 数日から数週間 にわたって段階的に配布される
  • 今回のビルドの全変更一覧は log で確認できる

セキュリティ修正: CVE-2023-4863

  • 今回のリリースには セキュリティ修正 1 件 が含まれる
  • 外部研究者が貢献した主な修正は次の脆弱性
    • Critical CVE-2023-4863: WebP のヒープバッファオーバーフロー
    • バグ番号: 1479274
    • 報告者: Apple Security Engineering and Architecture(SEAR)、University of Toronto Munk School の The Citizen Lab
    • 報告日: 2023 年 9 月 6 日
    • 報奨金額: $NA

実際の悪用と情報公開の制限

  • Google は CVE-2023-4863 のエクスプロイト が実環境で存在すると明らかにした
  • バグの詳細情報やリンクへのアクセスは、大多数のユーザーが修正版へアップデートするまで制限される可能性がある
  • 同じバグが、他のプロジェクトも依存している サードパーティライブラリ に存在し、まだ修正されていない場合にも制限が維持される可能性がある

セキュリティバグの検出と報告経路

関連記事

1件のコメント

 
GN⁺ 2023-09-13
Hacker News の意見

  • Google Chrome では WebP 画像はレンダラープロセスでデコードされるため、エクスプロイトが成功しても、サンドボックス内でのレンダラーコード実行までに限られる
    レンダラーは非常に複雑なので毎年多くのエクスプロイトが見つかるが、レンダラーでコード実行を得ても、通常のWebページが持つ権限を大きく超えることはできない
    特にローカルファイルシステム上のファイルを見たり残したりすることはできず、別ドメインのCookieも読めない

    • もちろん、これに組み合わせるサンドボックス脱出エクスプロイトがあるなら話は変わる
      ただちに最優先というわけではないが、野生でそうしたエクスプロイトがすでに出回っているのでなければ、大きな不便がないタイミングでできるだけ早くパッチを当てるべき
    • 現代のインターネットにはユーザーがアップロードした画像がものすごく多いので、単一Webサイトのユーザーコンテキスト権限を得るだけでも十分に大きい
      1つのサイトやフロントエンドに縛られないという点で、強化版XSSに近い
    • ロスレスWebPを使っているが、PNGよりずっと効率がいい
      あ、間違ったスレッドに付けてしまった。https://news.ycombinator.com/item?id=37479576 の「jpeg is good enough」への返信のつもりだった
    • レンダラーがWebサイトへ情報を送り返せないという意味なのか？
      それにJavaScriptをオフにしていても、突然Webサイトが依然としてコードを実行できるようになるということではないのか？

  • だから、ブラウザ開発者が新フォーマットの導入に慎重なことに、より共感するようになった
    WebPはJPEGに対する利点が大きくなく、主に透明度くらいで、成功も限定的だった
    それなのに今や複数の高優先度のセキュリティホールにつながり、libwebpにリンクしているあらゆる場所で、今後1か月にわたってパッチを配布しなければならない状況だ
    新しいことをするなという意味ではないが、開発者はコストをかなり大きく過小評価しがちだと思う

    • Firefoxには、プロセス全体ではなく個別ライブラリに適用できる追加のサンドボックス層がある: https://hacks.mozilla.org/2021/12/webassembly-and-back-again...
    • 公平に言えば、過去にもJPEGデコードライブラリの問題がマルウェア配布経路として使われたことがある
      WebPエコシステムがはるかに未成熟なのは確かだが、より古いフォーマット処理コードにもセキュリティ問題はかなりあったはずだと確信している
      それでも論理は妥当だ。数週間前までは、ネットユーザーたちはJPEG XLをできるだけ早く導入すべきで、そのためにはブラウザ開発者が「参照デコーダーのコードをコードベースに含めるだけ」で「コストはほとんどない」と主張する雰囲気だった
    • ブラウザが新フォーマットを採用していなければ、こうしたバグは見つかっただろうか？
      他の画像フォーマットやライブラリもバグだらけである可能性は高いが、主要ソフトウェアで使われていないので誰も気にしない
      特に、こうしたバグを見つけて悪用できる能力のある人にとっては、時間に対する見返りが悪いからだ
      長く使われないからといってバグが減るわけではない
    • セキュリティホールの原因は新しい画像フォーマットではなく、C/C++のメモリ安全性の欠如だ
      画像エンコーダーとデコーダー、そして他のエンコーダー/デコーダーが安全でない言語を使わなければ、こうしたバグを作り込む可能性は低くなる
    • WebPはJPEGよりはるかに複雑なフォーマットであり、複雑度は欠陥密度とほぼ直接相関する
      それとは別に、必要以上にコードを複雑にする文化や、細部をきちんと理解していない開発者たちも問題だと思う

  • この修正は今日の Firefox 117.0.1 と Fenix 117.1.0 に入っている: https://hg.mozilla.org/releases/mozilla-release/rev/e245ca21...

  • 参考までに、image crateには安全なRustで書かれた WebPデコーダー実装 がある: https://github.com/image-rs/image
    長い間かなり未完成だったが、昨年多くのWebP機能が実装された
    Chromiumは今ではRust依存関係の使用を認めるポリシーがあるので、Chromiumも導入を始められるのではないか？

    • Chromeに「遅くなる可能性があってもXYZライブラリの安全なバージョンを使う」フラグがあるなら、性能低下を受け入れてすぐに有効にするだろう
    • 2023年にもなって、Webブラウザのように攻撃面が巨大な対象に新しいC/C++コードを使い続けているのは、ばかげているように感じる

  • 問題の元のコミット: https://github.com/webmproject/libwebp/commit/f75dfbf23d1df1...
    このバグを修正するコミット: https://github.com/webmproject/libwebp/commit/902bc919033134...
    元のコミットはハフマンデコーダを最適化したもの。このデコーダはよく知られた最適化を使い、Nビットを先読みして、実際に何ビットを消費すべきか、どのシンボルをデコードすべきかを決める。あるいは、複数シンボルのNビット接頭辞であれば、残りのビットについてどのテーブルを参照すべきかを決める。
    旧バージョンは短いシンボルにはルックアップテーブルを使っていたが、長いシンボルにはグラフ探索が必要だった。新バージョンはルックアップテーブルの配列を使って改善した。各エントリは (nbits, value) を持ち、nbits は消費するビット数、value は通常シンボルである。ただし nbits が N を超える場合、value はテーブルインデックスとして解釈され、nbits はそのサブツリーで最も長いコード長として再解釈される。そのため、後続の各テーブルは 2^(nbits - N) 個のエントリを持つ必要がある。ルートテーブルは常に 2^N エントリに固定される。
    新バージョンはシンボル数を基準に最大エントリ数（kTableSize）を計算していた。当然ながらハフマン木は信頼できない入力に由来し、nbits が非常に大きくなるケースは容易に想像できる。VP8 Lossless では具体的に最大15ビットまで許容されるため、すべての LUT がそれぞれ別個の補助テーブルにマップされると、可能な最大テーブルは 2^N + 2^15 エントリになる。これを作るのにもそれほど多くのシンボルは必要なく、各テーブルにつき 16-N 個のシンボルで十分である。
    興味深いことに、コード自体にはテーブルサイズだけを計算するモード（root_table == NULL で VP8LBuildHuffmanTable を呼ぶ）があったが、なぜか使われておらず、固定の最大サイズを仮定していた。そのため、エントリ数が最大になるようにハフマン木を作ると、割り当て領域を越えて書き込んでしまう。
    なぜこうなったのかは理解できる。ハフマンデコード段階は多くの圧縮フォーマットで計算量が最も大きい部分の一つなので、小さな改善も重要だ。上記の最適化はよく知られているが、長いコードパスは一般にまれだと考えられており、最適化の優先度は低かった。元のコミットメッセージはこの仮定に反論し、マージされ得た。メモリ安全な言語がこの問題を防げたかどうかも確信しにくい。珍しく、ここではオーバーフローチェックを積極的に避けたくなるケースだからだ。
    [1] ただしメモリ破壊はタイトなループではなくテーブル構築中に発生するので、部分的なオーバーフローチェックは大いに役立ったはずだ。実際の修正では ReadSymbol 関数はまったく変更されていない。それでもタイトなループの安全性は正当化される必要があり、誤った正当化はすべてを台無しにし得る。

    • このコンポーネントは WUFFS で書くべきだった。
      境界チェックが不要だという話が正しいなら問題ない。WUFFS はランタイム境界チェックを出力しない。
      しかし今回のように、ソフトウェアが境界を越えていて誤っている場合、WUFFS ではコンパイルされない。
      「それは不可能だ」と思うかもしれないし、WUFFS が汎用プログラミング言語ならその通りだ。ライスの定理によれば、非自明な意味的性質は決定不能である。
      幸い、WUFFS は汎用言語ではない。ほとんどのソフトウェアは WUFFS では書けないが、画像コーデックは書ける。
    • C プログラマとして働かなくなって10年以上経つし、もともと得意でもなかったが、説明を見る限り、境界チェックが問題を捕まえられたはずだという点には同意する。
      ただ、この種の問題を捕まえる自動テストを作れたのかも気になる。
      個人的に扱うコードでは、一部の計算を別関数に切り出して独立にテストできる。ここでは性能のために難しかったのかもしれないが、確信はない。

  • BuildHuffmanTable の 範囲外書き込み の修正
    https://github.com/webmproject/libwebp/commit/902bc919033134...

    • その直後に oss-fuzz に関連する別のコミットがあるのも興味深い: https://github.com/webmproject/libwebp/commit/95ea5226c87044...
      Google がこのバグを見つけた後、libwebp 用のファザーを最適化し、その結果さらに多くのバグを見つけている、という意味かもしれない。

  • Apple が報告したもののように見え、このセキュリティアップデートと非常によく似ている: https://support.apple.com/en-us/HT213906

    • Apple と「UoT Munk School の Citizen Lab」が報告したもので、リンク先ページにも正確にそう表記されている。
      そのため、かなり可能性は高そうだ。Apple が内部的に ImageIO で libwebp を使っているか、似たようなミスをした可能性がある。
    • 先週と今の反応がどれほど違うかを見るのは興味深い。

  • 画像コーデックには脆弱性の長い歴史がある。
    実際の画像処理は、メモリ安全な FORTRAN IV でも書けるほどきれいな線形コードになり得るが、圧縮が入ると可変長データ構造やポインタ追跡などが多くなる。
    そこに高速に実行しなければならないというプレッシャーも加わる。

  • これも Electron に影響があるのか？ もしそうなら、どのバージョンなのか？

  • これを現実的に悪用する経路はあるのか？
    聞いたところでは、64ビットでは ヒープスプレー はもはや実用的ではないらしい
    メモリ内に上書きできる予測可能なオブジェクトがあるのか？

    • すでに野生で悪用されているので、答えは「ある」だ
      64ビットでもカーネルエクスプロイトではヒープスプレーは今でも確実に使われている。V8 エクスプロイトで人々がどんなプリミティブを使っているのかはよく分からない