Chrome と Edge のゼロデイ脆弱性を修正するアップデートが公開

** 本記事は、Chrome and Edge fix zero-day security hole – update now! の翻訳です。最新の情報は英語記事をご覧ください。**

24 件のセキュリティホールを修正した Chrome の前回のアップデートからわずか 3 日後、Google は Chrome 105.0.5195.102 のリリースを発表しました。バージョン番号の4 組の数字のうち最後の数字が、Mac と Linux では 52、Windows では 54 から 102 へ更新されています。

Apple から引用したと思われる文言が並んでいる Google のリリースノートにて、以下を確認することができます。

   CVE-2022-3075: Insufficient data validation in Mojo.

   Reported by Anonymous on 2022-08-30

   [...]

   Google is aware of reportsrts [sic] that an exploit 
   for CVE-2022-3075 exists in the wild.

Microsoft は Chromium をベースにしたブラウザを対象に、Edge 105.0.1343.27 へのアップデートを完了しています。

Google の超簡易的なスタイルに倣って、Microsoft はシンプルに下記のように記しています。

   This update [Edge 105.0.1343.27] contains a fix for CVE-2022-3075, 
   which has been reported by the Chromium team as having an exploit 
   in the wild

いつものように、この曖昧な方法で書かれたセキュリティホールに対するソフォスの解釈は、「サイバー犯罪者やスパイウェア業者は、セキュリティベンダーより先にこの脆弱性を発見し、それを悪用する方法を考え出し、すでに実行している」ということです。

EoP と RCE

このバグが入力データの不正な処理に関連していることから、バグが EoP (特権の昇格) のような懸念すべきセキュリティ結果につながるのか、それとも RCE (リモートコードの実行) のような、より悲惨な結果をもたらすために悪用されるのかを判断したいところです。

EoP は通常、マルウェアを標的のマシンに感染させる足がかりが必要となるため、EoP のバグのみでは侵入のための攻撃は成立しません。

しかしパッチの適用は不可欠です。なぜなら、攻撃者はゲストのようなユーザーを装ってコンピュータに忍び込み、EoP エクスプロイトを持ち込んで、ルート権限やシステム管理者権限を獲得し、1 台のコンピュータに限定されていたリスクを、ネットワーク全体を侵害するために拡大させようとすることが多いからです。

一方、RCE エクスプロイトを悪用する目的は、ネットワーク内に前線を張って攻撃を開始するため、あるいは一旦侵入したコンピュータから別コンピュータへ繰り返し移動するため、あるいはこれらの両方であることが多いです。

繰り返しますが、Google の報告が簡易すぎたことから、このバグ報告の深刻度は「重大」であり「緊急」ではないものの、当記事ではより危険である RCE について書いていると認識してください。したがって、スキルの高い攻撃者はこのバグを悪用してゼロからマルウェアを標的のマシンに移植できると想定できます。

Mojo と IPC

Mojo は Google のコードライブラリで、IPC (プロセス間通信) の略称として知られています。

最近ではセキュリティ上の理由から、一般的にブラウザは、単一のモノリシックなオペレーティングシステムのプロセスとして実行されません。

簡単に言うと、プロセスは複数のスレッドで構成されます。これらのスレッドは基本的にメインプロセス内の「サブプロセス」であり、これによって 1 つのプログラムはドキュメントをスクロールしている間に印刷したり、バックグラウンドでスペルチェックを行ったりなど、同時に 2 つの処理を実行できます。

1 つのプロセス内のすべてのスレッドが同じメモリのチャンクにアクセスできるため、シングルプロセスのアプリケーションをスレッドに分割することが、プロセスを別々に分割するよりも好都合です。これは、速くて簡単だが、安全性は低いことを意味します。

つまりスレッドは、現在の構成設定のチェック、メモリアドレスの交換、ファイルハンドルの共有、RAM から直接キャッシュされた画像の再利用など、同じ共通のデータプールに直接アクセスするだけなので、より簡単にデータのやり取りと共有を行うことができるのです。

一方、1 つの大きなメモリ空間を共有するということは、プログラムの一部、たとえば最初のブラウザタブを忙しくレンダリングして表示しているスレッドのバグが、他の部分、たとえば開いているタブの残りを処理しているスレッドなどに影響を及ぼす可能性があります。

そのため最近のブラウザでは、各タブを独立したプロセスで処理するなど、多数のプロセスに分割しています。それにより、あるタブが想定外の方法で処理されるときに、まったく別の Web サイトに関連する他のタブのクッキーやアクセストークンなどのデータが、些細なことで流出しないようにすることが一般的です。

プロセス間通信

ブラウザの各プロセス間でデータをやり取りするためには、安全で信頼性の高い方法が必要です。

タブ A とタブ B は、ブラウザのメインスレッドにある共通のメモリブロック M を参照するだけではなく、タブ A とタブ B の独立したプロセスに、それぞれ必要なデータのコピーが提供される必要があります。

そこで、プロセス間通信システム (IPC) が必要になります。

IPS を介して自分たちの間でデータをシャッフルするプロセスは、送信のためにデータを正しく構築する方法と、相手側で安全にデータを分解する方法について合意する必要があります。

これは、専門用語でシリアライゼーションデシリアライゼーションといいます。これは、おそらくはすでにメモリのさまざまな領域に保存されているコンテンツからデータのチャンクを抜き出し、それらのチャンクを「ここにあなたが知る必要のあるデータ項目、タイプ、値のあなた自身の記録があります」という構造化されたリストに変換していることに由来します。

シリアル化されたデータは、共有メモリブロック、オペレーティングシステムレベルの通信パイプ、ネットワークリンク、あるいはモールス信号で別のプロセスに送信され、受信者は送信者プロセスの現在または未来の内部状態を知ることなく、データを理解し、独立して解凍できるようになります。

たとえば、A が B に 128 バイトのブロブを送る場合、2 つの 32 ビット整数と 2 つの 64 ビット浮動小数点数 (ここまでで 4+4+8+8=24 バイト)、1 バイトの 0x67 (10 進数で 103)、そして 103 バイトの ASCIIテキスト (全体で 4+4+8+8+1+103=128 バイト) が続く形になります。

あるいは、120 バイトの UTF-8 テキストメッセージで、スペースを埋めるために必要ならゼロでパディングされ、それを表示する画面上のウィンドウの幅と高さを示す 2 つの 32 ビット数字が続く形になるでしょう。

送り手と受け手の解釈が一致しない場合

ご想像の通り、IRC で受信したデータを間違って解釈したり、利用する前にデータの意味を確認しなかったりすると、深刻な結果を招く可能性があります。

最初の例では、文字列長バイトが残りのデータ量よりも大きなサイズ (たとえば 0x67 ではなく 0xFF) を示す場合、その誤ったサイズのバイトを盲信すると、バッファの終端を越えて読み込んでしまうことになります。

2 番目の例では、プロセス A が幅と高さのデータを忘れて、代わりに128 バイトの UTF-8 テキストを送信した場合、最後にある 2 つの 32 ビット数をやみくもに「デコード」すると、おそらく危険なほど間違った値を生成することになります。

画面上のウィンドウに割り当てるストレージのバイト数を計算するために、これらの不正確なエンコード数を掛け合わせると、おそらくどこかでメモリの誤操作の問題に直面することになります。

理想的には、送信者は IPC データ出力を送信する前に検証し、受信者は IPC 入力を消費して使用する前に独自に再検証しますが、[a] それは常に起こるわけではなく、[b] たとえ起こったとしても、それぞれの端で一貫性のない検証手順があると、結局それが問題になってしまうことがあります。

つまり、連携しているプロセス間でやり取りされる IPC データの「データ検証不足」は常にバグであり、今回のように深刻な事態を招く可能性があるのです。

対策

早期に、そして適切なタイミングでパッチを適用しましょう。

Chrome の場合、「…」「ヘルプ」「Google Chrome について」をクリックするか、専用 URL である chrome://settings/help にアクセスして、最新版であることを確認してください。

パッチが適用されている Chrome のバージョン (または非専売、オープンソースのタイプを使用している場合は、Chromium のバージョン) は、105.0.5195.102 以降です。

Edge の場合は、「…」「ヘルプとフィードバック」「Microsoft Edge について」をクリックして確認してください。

パッチが適用されている Edge のバージョンは 105.0.1343.27 以降です。

Google のリリースノートには、拡張安定版のチャンネルへのアップデートも記載されています。仕事によって提供されるコンピュータには、拡張安定版が使用されているかもしれません。これは、Mozilla の拡張サポートリリースまたは ESR のように、機能的には遅れていても、セキュリティパッチには対応している正式版なので、パッチを受けるためだけに新しい機能の採用を強いられることはありません。

パッチが適用されている拡張安定版のバージョンは、104.0.5112.114 です。

Google はまた、(いつものように) App Store経由で入手可能な iOS 用 Chrome のアップデートを公開しました。

iOS のバージョンが CVE-2022-3075 の影響を受けるかどうかについて言及はありませんが、バージョン 105.0.5195.100 を使用してください。

(Google は「iOS」という単語によって iOS と iPadOS の両方を指していると思われます。現在、iPadOS は Apple の基礎となるモバイルオペレーティングシステムの異なる亜種として出荷されています。)

これまでのところ (協定世界時 2022-09-05 13:45 現在)、リリースノートには Android について何も記載されていません。最新情報については、Google Play をチェックしてください。