The Deathray: A simple way for an untrusted site to freeze a Mac

This has been around since 2011 when WebGL shipped. It's documented in the spec. It's a self correcting problem. You go to a site, it freezes your machine, you never visit the site again.

No data is stolen, no privacy is lost. All that happens is the perp loses any audience.

Turning off WebGL = no more Figma, no more Canva, no more Google Maps. A few self correcting sites seem acceptable. Evidence, it's been 15 years since this was possible and the world didn't end and the whole internet isn't freezing your machine.

Also, this is arguably a MacOS bug. Window and Linux have had GPU monitors that power cycle the GPU if a command takes too long. Windows since before WebGL shipped. Linux a few years after. Macs still don't recover from excessive GPU use.

> Just hope that your browser doesn't automatically reopen the same tab when it starts up again

Busted. My browser is configured to do just that.

Back in the 90s when the web was non-commercial and fun, I added a "Don't Click Me" link that loaded a 'browser test' page (after a series of "are you really really sure?" dialogs) that exploited every historical browser bug I could find. Infinite popups, inescapable dialogs, ActiveX quirks, various hangs and crashes, the works.

If it didn't crash your computer, it eventually displayed a single popup that said "Congrats on not using Internet Explorer!". I wish I still had the hate emails.

Metal is based on C++14, which means you can write Duff's Device in a shader. I've tried it on various Macs and it causes all sorts of critical failures in the compiler, but never an actual kernel panic. (It's pretty trivial to reproduce in KodeLife)

Huh, this completely crashed my Firefox on Linux, which I've never had happen before. At least the rest of the programs on my desktop seem to have been completely unaffected.

On Graphene OS, it froze Brave, but Vanadium was able to deal with it swiftly. Not sure if that has anything to do with JavaScript JIT.

Tried it and now I cant boot even in safe mode. I love it

While I'm sure it has its uses, particularly if someone really does want to game or do complex computational stuff purely within a web browser, I'll admit I've grown pretty cautious/tired around the ever increasing amount of hardware attack surface area the browser vendors seem to be rushing to expose as Google in particular appears determined to try to be the "operating system on the operating system" as much as it can. In this particular case it made me realize I'd awhile ago set dom.webgpu.enabled and pdfjs.enableWebGPU to false in Firefox, same as I disabled WebGL. Kinda figured if I ever saw something ultra cool I could enable it just that one time but so far I haven't. Semi-related, reviewing the available settings now for the first time in a bit I notice they have a dom.webgpu.blocked-domains with the sole entries being "easyeda.com,*.easyeda.com", I wonder what that's about?

it crashes this hardware apparently:

  - macOS 14.7.3 (23H417)
  - Chrome 152.0.7977.84
  - Hardware: MacBookPro17,1 (Apple M1)

I want to click it so bad, but I can't bring myself to do it.

Remember when that unicode string nuked iOS 7 and you could set it as your SSID to get them stuck in a loop? good times.

Froze my Brave browser on Windows for about 10 seconds. Every page turned white. then they refreshed and worked again, except the offending page. As the author speculated that tab was frozen.

There are more of these hiding in WebGPU. Some work on iOS as well. I reported them to Apple but they were closed as not having security relevance.

On a Windows 11 work machine - this is causing my Teams to blink black and come back randomly. Yes I used my work machine.

I supposed you could just turn it off?

In Chrome on Linux:

WebGPU is experimental on this platform. See https://github.com/gpuweb/gpuweb/wiki/Implementation-Status#... deathray/:9

Failed to create WebGPU Context Provider main @ deathray/:9 (anonymous) @ deathray/:113

Uncaught (in promise) TypeError: Failed to execute 'configure' on 'GPUCanvasContext': Failed to read the 'device' property from 'GPUCanvasConfiguration': Required member is undefined. at main (deathray/:17:17)

>This spills over into other processes wanting to use the GPU, namely the WindowServer.

Why does this spill over? Unlike CPU which is multiplexed by the kernel's scheduler (so infinite loops can't lock out other programs), is the GPU not multiplexed in the same fashion?

> I was surprised when it hung my computer and of course asked "Does it do that every time?"

A true scientist! (see https://xkcd.com/242/)

This issue is older than the M chips: a formative OpenCL moment on my Intel MacBook involved locking it up in this way. By contrast, a similar CUDA kernel running on Linux was forcibly stopped after some short-ish time.

Worse and less defensible on the web of course.

Is there a reason you need the fake for loop and the vertex shader? Can a single infinitely looping shader not do the same thing?

And what happens in WebGL?

I was lucky, the website is down due a certificate error.

Jesus Christ! My mac reopen the windows when it restarts. And it opens the Deathray again! I had to quit safari immediately I saw the dot below its icon. And it took me yet another restart to fix the weird problems in other apps.

Could be a useful way to force user-interaction-gated flows. A "your computer is infected, click this button in 10 seconds or it will crash" type button which, at this point, most modestly-knowledgeable users would know not to click. However, after seeing their computer actually crash when the countdown hits 0, perhaps they would be more inclined to click "allow" on whatever prompt follows when they see it again.

Of course, plenty of other uses. Disable your adblocker or we crash your computer. Watch the whole ad or we crash your computer. Click the follow button or we crash your computer.

Maybe I'm crazy, but "crash your computer" as a building block seems powerful enough to be a security issue. Is denial of service not a security thing anymore?

Amazing!

I encountered the same type of death freeze when trying (and failing) to run models in browser tabs, but didn't spend much time trying to understand how severe it is.

Hope they don't disable WebGPU...

It's at best denial of service. Except it's easily avoidable by never going back to that site again.

The funny thing is the page describing the problem stutters like crazy in firefox/mac while the rotating nuclear hazard wheel is displayed.

It freezes a Pixel 10 on Chrome, Webviews and Brave..!

I tried several webview-based browsers, Chrome, and Brave, with them the phone completely freezes (except that the audio keeps going for a bit).

I tested webview browsers because by chance the first place I ran it on was Telegram's internal browser (on which the phone does freeze).

It doesn't do anything on Firefox though, and weirdly enough not even on the Chromium-based Cromite (after enabling WebGL).

I only tried waiting for a few minutes, but it wasn't giving signs of life.

If someone wants to try, keep in mind that to force restart a Pixel you have to press the power button for 30 seconds (during which you might break out in a cold sweat).

Is this why Oregon Trail Deluxe freezes on Mac?

https://oregontrail.ws/games/the-oregon-trail-deluxe/play/

It kind of froze my Mac Studio M2 Ultra, but I was able to still move the mouse and force-quit Safari using Command+Q. Once I did, everything immediately went back to normal.

Does this reproduce with just the compute pass, or does WindowServer deadlock on the canvas drawable?

    while (true) console.log('this will freeze/crash dev tools') 

For more of a "I've been hacked!" effect, load infinite 3D models in Three.js that have millions of vertices each. You get those black boxes where the system has so low RAM it can't even draw the browser window.

Apple Silicon Macs have a lot of GPU problems. I find that after running any significant GPU workload, the entire operating system starts getting super slow until a reboot. Even if the entire process tree that ever touched the GPU has been completely terminated for days.

> recoverable data loss which we do not consider to be a security issue

How about the irrecoverable loss of data in RAM, though?

It's very easy to lock up your browser or machine with WebGPU, it happens on Windows too. You'll do this by accident constantly in a big WebGPU project, until the Chrome GPU trace/renderdoc/nsight shows some crazy deadlock bottleneck you have no hope of understanding at the browser level.

GPU driver engineering has received a tiny fraction of the resources of CPU engineering, while being significantly more complex. And GPU users will not pay for performance hits that better the architecture, they will just buy the other guy's GPU/use their driver. So it's a race to the top with performance and race to the bottom with architecture and stability.

Absolutely no effect on Firefox on Android 16, same with Vivaldi on W10. Everything works normal, not even higher CPU load, just shows some blank page.

Not 100% surprised that this wasn't picked up as a security issue; denial-of-service is bad, but ultimately doesn't give you a direct path to stealing secrets / hijacking identity / etc.

It is pretty egregious though, I hope they fix this. I expect there'll be a Radar tracking this now that it's made it to the HN front page.

This froze my S26 Ultra on chrome

Zero impact on iOS 27.

[flagged]

[flagged]

Maybe that would be better than a meltdown . . .