WebP 0day

• Google は最近、Chrome 向けの安定版アップデートを公開し、Apple の SEAR チームが報告した WebP 画像ライブラリのヒープバッファオーバーフローに対するセキュリティ修正を含めた
• 既知の脆弱性 CVE-2023-4863 は実環境で悪用されており、つまり誰かがこの脆弱性を利用したエクスプロイトを使用していたことを意味する
• この投稿では、CVE-2023-4863 の技術的分析と、"WebP 0day" としても知られる概念実証トリガーを提供している
• 脆弱性は WebP の「可逆圧縮」サポートにあり、これはピクセルを 100% の正確性で保存および復元できる可逆画像形式である
• この脆弱性は、Huffman コードの複雑さとバグをトリガーするために必要な特定条件を考えると、手動のコードレビューによって発見された可能性が高い
• このバグは広く使われているオープンソースライブラリに存在する強力な脆弱性であり、ファジングが難しいため重大なセキュリティ問題となっている
• このバグは、BLASTPASS 攻撃で使われたものと同じ脆弱性である可能性が高く、これは iMessage に対する「ゼロクリック」エクスプロイトを使って NSO Group の Pegasus スパイウェアを配布することに関係している
• この投稿は、このような攻撃がどのように機能するかに関する基本的な技術的詳細を差し控えることは、攻撃者よりも防御側に利益をもたらし、情報の非対称性を生むと示唆している
• 著者は、能動的なソースコードレビューへのより大きな投資と、パーサーが適切にサンドボックス化されることへの重点によって、セキュリティを向上させるよう呼びかけている

[GN⁺]

Hacker Newsの意見

• WebP画像形式のバグに関する記事で、2015年のTimsortバグと比較されている
• 公式に証明された最大テーブルサイズとソースコードに入力された値の不一致によってバグが発生した
• 形式的検証の必要性とメモリ安全な言語を使う重要性が強調されており、人間のレビューのみに依存するのは不適切だとしている
• 位置と修正方法が知られているにもかかわらず、悪用の概念実証（POC）の再現が難しいことに言及している
• Braveのような他のChromiumベースのブラウザも影響を受けたのか、問題がモバイルだけに限定されていたのかという疑問が提起されている
• NSOがバグを見つける上でソースコードがどのような役割を果たしたのか、コードがblob-onlyだったとしても現代のデコンパイラで十分だったのではないかという推測がある
• 画像を見るだけでもセキュリティ問題が発生しうるという懸念が示されている
• JPEGで使われている何十年も前の技術であるHuffman圧縮にバグが存在したことが驚きとして受け止められている
• WebP仕様はコードの構成方法に関する明確さが不足しているという批判がある
• AppleとChromeの迅速な対応は称賛されている一方、Linuxディストリビューションに関連してGoogleの問題対応は批判されている
• このように世界中で何百万人にも使われているライブラリは、リスクの高さを考えるとCを使うべきではないという主張がある
• 記事の要約がfuzzingに過度に依存しており、解決策としてコードレビューとサンドボックス化を提案していること、そしてメモリ安全な言語の使用を主張していないことへの批判がある