デスレイ：信頼できないサイトがMacをフリーズさせる簡単な方法

デスレイ：信頼できないサイトがMacをフリーズさせる簡単な方法 2026年9月10日 TL;DR 信頼できないサイト上のWebGPUシェーダーがMacのグラフィックをハングさせ、再起動を強制するまでデスクトップUIを使用不能にすることができます。被害者はリンクをクリックするだけで済みます。この問題はmacOS上でブラウザを横断して再現しますが、他のOSでは再現しません。 デスレイを試してみてください！ 上記のボタンはあなたのMacをフリーズさせます。他のOSでは遅くなる可能性があります。 テストした他のOSでは、タブがフリーズし、動作が重くなりますが、タブを閉じれば問題ありません。ただし、結果は異なる場合があります！コンピューターをフリーズさせても構わない場合のみ、上記のボタンをクリックしてください。 範囲 Chrome、Firefox、SafariのmacOS上でデスレイを再現しました。他のオペレーティングシステムでは再現しません。MシリーズMacBook（Tahoe実行中）でのみテストしましたが、他のMacも影響を受けるかどうか興味があります。 どのように機能するか？ デスレイは比較的新しいウェブ技術であるWebGPUを使用しています。WebGPUは、サイトがデバイスのGPUで実行するためにシェーダーを送信できる組み込みブラウザAPIを提供します。これはWebGLに取って代わることを目的としており、ほとんどのOSのすべての主要ブラウザでサポートされています。 デスレイ全体は単一の小さなファイルに収まります。ソースコードはこちらで見ることができます。ファイルの大部分は足場であり、重要な部分はWebGPUシェーダーです。 Compute Shader @group(0) @binding(0) var<storage, read_write> data : array<vec4f>; @compute @workgroup_size(1) fn compute() { // i++なし、ループは無限にスピンします for(var i = 0u; i < 1;) { data[i+1] = data[i]; } } Render Shaders @group(0) @binding(0) var<storage, read> data : array<vec4f>; @vertex fn vert(@builtin(vertex_index) vertexIdx : u32) -> @builtin(position) vec4f { // コンピュートシェーダーが書き込むのと同じバッファから読み込もうとします let datum = data[vertexIdx]; return datum; } @fragment fn frag(@builtin(position) pos : vec4f) -> @location(0) vec4f { return pos; } コンピュートシェーダーでは、無限のビジーループがバッファ内の同じベクトルを繰り返しコピーします。頂点シェーダーは、コンピュートシェーダーが操作しているのと同じデータバッファに依存しています。コンピュートシェーダーがビジーループで忙しいため、頂点シェーダーは前進できません。これは、WindowServerなど、GPUを使用しようとする他のプロセスに波及します。WebGPUの積み上げの結果、WindowServerも応答しなくなります。 これは常に同じように現れるわけではありません。マウスを動かせることもあれば、そうでないこともあります。ビーチボールが表示されることもあれば、画面の一部にマゼンタ色のゴミが表示されることもあります。異なる動作につながるものが何であるかはわかりません！ 興味深いことに、この時点ではコンピューターの他の部分は問題ありません。SSHでコンピューターに問題なく接続できます。しかし、WindowServerをチェックするウォッチドッグがあります。応答がない時間が長すぎると、カーネルパニックがトリガーされ、コンピューターが再起動します。デスレイされた場合で、我慢できない場合は、ウォッチドッグを待たずに電源ボタンを長押ししてオフにして再起動できます。起動時にブラウザが同じタブを自動的に開き直さないことを願っています :) 前例 これは実際、Appleがこの問題に直面したのは初めてではありません。2023年、ImpervaのRon Masasは、WebGLを使用したShadyShaderという同様の悪意のあるシェーダーを作成しました。ShadyShaderも暴走ループを使用してGPUを占有し、技術的には無限ではない巨大なネストされたループを作成しました。Appleは、CVSSスコア6.5（中程度）のCVE-2023-40441を発行して対応しました。問題を軽減するために、Appleは暴走ループをより良く検出するために、入力検証を改善しました。その入力検証はWebGPUでは弱いように見えます。デスレイには、容易に識別できる無限ループがあります。しかし、最終的に無限ループを検出することは負け戦です。停止問題（halting problem）を回避することはできません。応答しないシェーダー、特に信頼されていないコードを実行しているシェーダーの、より良いプリエンプションが必要です。テストした他のすべてのオペレーティングシステムはこれを正しく行っています。 Appleがこれらのタイプの問題を修正する際に直面する課題の一部は、Mシリーズチップのアーキテクチャによるものかもしれません。OSカーネルはGPUを直接プリエンプトできません。代わりに、GPU処理はASCとして知られるコプロセッサによって実行され、OSカーネルはそれと通信します。GPUプリエンプションロジックはすべてASCファームウェアにあります。Asahi Linaは、MシリーズGPUに関する優れた記事で、アーキテクチャをさらに詳しく探求しています。 デスレイはどうやって見つかったか？ この問題は昔ながらの方法で見つけました。偶然です！Recurse CenterでWebGPUを学んでいて、誤って無限ループを作成してしまいました。コンピューターがハングしたときに驚き、もちろん「毎回そうなるのか？」と尋ねました。確かにそうです！これを偶然見つけたのは私が最初ではないはずです。 開示 この問題は2026年7月27日にApple Securityに開示されました。Appleは迅速に問題を再現し、修正する意向であると述べました。彼らは機密とされた修正タイムラインを提供しましたが、ここでは記載しません。しかし、2026年8月26日、Appleは方針を変更し、「[私の]レポートにセキュリティ上の影響はない」と述べ、「[Appleの]製品に変更をもたらすものではない」としました。レポートは「潜在的な機能強化の検討」のために別のチームに送られるとのことでした。私には、それが修正されるとしても非常に優先度が低いように聞こえます。ShadyShaderが6.5の中程度の深刻度を持つ問題としてマークされていたことを考えると、少し奇妙です。 とはいえ、何がセキュリティ問題を構成するかについて、興味深い議論ができると思います。私が話したセキュリティ研究者は、Appleの意見に同意する傾向があります。Appleが言うように、「結果はクラッシュ、ハング、または回復可能なデータ損失であり、セキュリティ問題とは見なしません」。そして技術的なレベルでは、彼らが間違っているとは思いません。しかし、私が話した非セキュリティ専門家の大多数は、その特徴づけと、Appleが問題を修正する優先順位を付けていないことに驚いています。多くの人々はブラウザを強く信頼していると思います。（おそらく誤った）信念として、単にリンクをクリックするだけで、タブが閉じられるまで遅くなること以外に、コンピューター全体に悪影響を与えることはないだろうというものです。デスレイのようなものは、その信頼を非常に目に見える形で侵害しており、ほとんどのユーザーはそれをセキュリティ問題と見なしていると思います。 私が期待すること デスレイは確かにサンドボックスエスケープ、RCE、またはデータ侵害ほど深刻ではありません。しかし、その参入障壁は非常に低い（誰かにリンクをクリックさせるだけでよい）ため、非常に迷惑になる可能性があります。悪意を持って使用された場合、それはRickrollのより意地悪なバージョンであり、Appleが近いうちに修正してくれることを願っています。（そしてApple、デフォルトでWebGPUを無効にしないでください！私はWebGPUを愛するようになりました💚）。 しかし、Appleが修正するまで、人々がそれを悪意なく楽しむ方法を見つけることを願っています。ユーザーが事前に同意した場合にMacがフリーズするデスレイビデオゲームを見てみたいです。「ゲームで死んだら、現実世界でも死ぬ」のずっと穏やかなバージョンです。 楽しんでください、猫たち、でも責任を持ってください！ 敬具、 Auberon López (they/them)