The Deathray: A simple way for an untrusted site to freeze a Mac
auberon.xyz
auberon.xyz
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.
I think this point of view is making it a bit too easy.
> I think this point of view is making it a bit too easy.
It's been 15 years since this was possible. How many times have you heard of this being an issue? Again, it's self correcting. Site freezes machine, user stops going to site. There's zero incentive to do this and tons of incentive to not do it. Even an ad, your ads would get banned, not good for you, no incentive.
Not true, given any unknown link or button press can redirect/go to such a site.
This is basically an old-man-and-the-starfish situation for me.
> You're making a big assumption that a user will even connect the dots
If they do, it’s because their wildly inaccurate mental model happened to guess the right answer. What most will think is “I was just browsing the internet and my computer froze.” Maybe they’ll connect it with that notification they just got about renewing their antivirus software subscription. Maybe it will confirm their (probably mistaken) impression that their computer has been “acting weird” since something arbitrary and unrelated happened. And similarly, some people with an accurate mental model will mistakenly assume that they deduced the cause because they’re smarter, rather than having a different focus with corresponding lacking mental models in other areas.
So to get it to stop doing this on restart, I had to be very quick to force-quit Safari as the machine rebooted. You don't get a chance to tell it "Don't reopen all windows" when you hold the power button down.
What about url shorteners and redirects?
You seem to dismiss the issue based on a very narrow avoidable case.
Sure, there are countless ways it could be abused, and you point out some, but what had actor will want to pursue even one? They gain nothing. And good actors only lose out, in the form of lost credibility and future audience. Therefore it doesn't get abused and a fix isn't needed.
The last 15 years is evidence of the argument.
> but what had actor will want to pursue even one? They gain nothing
Ask that to anyone who has ever rickrolled somebody.
That being said, IMO no website should be able to freeze your machine. This is a bug. Steps should be taken to fix it.
Through what mechanism? You don’t load their code, so then they presumably load this malicious code? If they could do that they would have just loaded the ad!
What do regular users do about a malicious ad that runs on thousands of different sites?
> Turning off WebGL = no more Figma, no more Canva, no more Google Maps
Which is why you should probably rather turn off the actual vulnerable API, i.e. WebGPU, not WebGL.
For example, an ad provider itself can be hacked by a malicious party, so the "pay money for" part no longer applies.
Or an attack by a state actor or other large entity, where paying for a coordinated disruption of some region or company makes financial or military sense.
Those are just two things that came to my mind, and are likely a fraction of plausible incentives someone might have now or in the future. People are creative and unpredictable. Weird shit happens. Fact is stranger than fiction...
Instead, just ask: should visiting a website ever have the power to freeze your computer without your consent? If you think the answer is no, this is a security bug and it should be fixed.
You haven't heard about rickrolling, have you?
Since the machine is actually frozen, it enables many plausible social engineering scams ("We have detected a virus that froze your machine. Call this number for help..."), and I bet it has been used that way.
Not to mention possible data loss, interruption of work at a critical time, and so on.
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.
If not, I have fond memories of using yours!
With that one, Ctrl+Alt+Delete, Task Manager, kill iexplore.exe was usually all you needed to do thankfully. No hard power off necessary.
My Intel Mac from 2015 could be up for months without interruption or slowdown. (mostly because I stopped updating after Mojave, but my point is it never needed a reboot)
Busted. My browser is configured to do just that.
You know what happens when your business is a browser and you gradually deprecate different functions of a browser, rather than refining and expanding on them?
When you switch to one of the other tabs, that's the first time they are actually instantiated and run. So if you had this tab in the background, your machine crashed, and Firefox reopened on boot, it would not crash again.
Often, it will report "We are having trouble restoring your session", seemingly without reason, and that dialog has a very simple system for choosing which windows and tabs to recreate vs which to discard. I think you can change a setting to always use this dialog.
I can't recall if chrome has the same interface.
I think near any anti-fingerprinting efforts though presume some floor level of system security and stability. If some particular hardware exposure feature lets attackers run arbitrary low level timing and hardware testing code or crash the system or break the sandbox the game is likely over for most people.
An extra bit of entropy isn't meaningless sure, but at some point there should be some weighing of absolute attack surface against it right? Some features just seem inherently anti-privacy/anti-security and one might just have to try to deal with that via other approaches.
Maybe it did and you're just hooked up to the Matrix thinking it didn't
WebGL is still putting people at risk:
CVE-2026-87464
CVE-2026-87488
CVE-2026-87438
CVE-2026-87527The only arguments I've ever heard in favor of wasm/webgpu were that using native graphics/GUI toolkit APIs are a pain. That's definitely true, because I've written stuff with gtk and it sucks, but that doesn't mean we should just shovel an entire tech stack into the browser.
Just because we can, doesn't mean we should. I'm tired of these BigCos shitting everything up.
Like, Tesco would prefer that my operating system was a roast chicken, Baowu Group would prefer it was made of steel, Berghain would prefer that it had to queue for hours to possibly get in, and Jagex would prefer it was an in-game GUI within RuneScape. None of those companies got their way, what makes Netscape special?
It's silly to complain now about BigCo, WebGPU, and ignore the past 20 years of history. The WWW has not been about document delivery only for the last 20 years. Instead of tiring themselves out complaining about the Web and modern browsers, they can use something else.
For WASM though, I do not agree at all! It's genuinely a great system for high performance browser code. So much stuff I use now had WASM as the backbone, and I even started applying it outside of the browser in some of my architecture. I wish we had way more enthusiasm behind things like WASM, and way less for something like WebUSB.
Is it really better for users to download and run straight up executables with no security model? We tried that in the 90s and 2000s and it was pretty bad. We can have OSes introduce a security model, like Android and iOS do. But then what about desktop Linux users like myself? Am I just to be excluded because I don't use a popular (and proprietary) operating system?
Okay, we can invent a standard, cross platform app distribution mechanism with a security model. And that's... exactly what web browsers are. In the end it seems like the least-bad solution to me. I quite like that I can run GPU accelerated programs without the dev having to put in special effort to support my Linux distro.
I dunno, maybe I'm missing an option?
Yes. Unambiguously, a system where the only code that runs is code that you explicitly run is more secure. Social engineering and basic tricks of telling someone an app does A while it really does B are not solved on the web, because social engineering cannot be solved. In the supposed safe gardens of app stores, apps do exactly that all the time and are not well moderated. Apple's supposed moderation approved a "Lastpass" password manager app that was not made by the actual Lastpass company. If that can get through, then anything can get through.
Meanwhile, the webapp solution is for any site you visit to be able to download and execute whatever they want, rather than whatever you want, and most sites also set a third party to have the ability to download and run whatever they want, and Google wants that system to have as much control over your local hardware as the OS does, so how is this better at all? It's strictly worse. The web security model is worthless. It depends on random third parties you have no affiliation with to not get hacked themselves, and not make stupid choices.
It's fine to just not have "Web bluetooth" actually. 800 "Partners" just don't need to be able to access that.
What is the "Security Model" of the web, that every random person willing to pay a few cents for an advertisement should be able to run code on your machine without your authorization? That anyone should be able to target individuals for RCE through advertising infrastructure?
I don't think so? If I want to run a 3D modeling program and I download their executable and run it, it has access to everything on my system. All my local files, open access to my network connection, whatever's going on with my internal network, etc. If they want to read all my files and upload them, they can just do that. This is not true for web applications.
Programs that run in a browser are sandboxed and only have access to what web standards say they have access to. They can open a file select dialog to get a file from my machine with my permission, but they don't just have access to all of my files like a local program does. Web standards developers put a lot of effort into finding a balance between security and capabilities for new web APIs.
> What is the "Security Model" of the web
Unlike locally running programs, web applications don't have access to everything on the system by default. Interactions with the local system are intermediated by the browser. Usually the user has to approve access, or there are limitations on what types of access a web app can have.
If you head into your Firefox settings and select "Permissions and data", you can see what kinds of things given websites are allowed to access. Usually when they first try to use one of those APIs, the browser will pop up some kind of browser-level dialog asking the user for permission to perform that type of action (eg "access local devices" or "show notifications"). These are all examples of the web app security model (and there's a whole lot more that is not as user-facing).
Local applications on the other hand, do not have any kind of security model. The 3D modeling program I downloaded can just package up all of my files and upload them to their server, completely silently. That's way worse than what web applications can do!
> It's fine to just not have "Web bluetooth" actually. 800 "Partners" just don't need to be able to access that.
In fact, they don't have access to that unless you give it to them. Bluetooth access is gated by a permission: https://developer.mozilla.org/en-US/docs/Web/API/Permissions...
I think we need to go the other way, all in on apps. The browser only has to expose permission based I/O, WebGPU and a way to build a11y semantic trees. Globally cached libraries can handle everything else. That would reduce the attack surface and core complexity while making the platform more flexible. HTML can run as a legacy layer on top.
I found this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1980392 and commit: https://phabricator.services.mozilla.com/D262053
It looks like per-domain WebGPU blocking was added exclusively just for easyeda.com !
Haven't read it all, but the story seems to be that EasyEDA's WebGPU usage was broken because it relies on some aspects which Firefox hasn't implemented yet. So they made this blocklist to get Firefox to behave as if it lacked WebGPU support completely on this domain, which makes EasyEDA fallback to some other non-broken version. Maybe they couldn't get in touch with EasyEDA directly, since it seems far easier to have them just disable WebGPU for some known versions of Firefox.
which seems like an insane thing to need or support. literally just pick a different name, there are infinitely many!
i can understand just deciding to ignore the site
Locked up my entire M1 Macbook Pro, held power button and I was back into chrome in <20s but I did kinda go "why did I just do that?"
And what happens in WebGL?
Interestingly though there was another way to make only the tab crash, even if I had all three shaders in the pipeline: If I placed the canvas far offscreen using position: absolute, only the tab would crash even if the render shaders were waiting! There's some weird interactions going on I don't yet fully understand.
When I click the death ray, it freezes Opera completely, and pins my 40 core GPU at 100% indefinitely.
However, contrary to what should happen, macOS continues merrily along. It lags a bit and some UI elements don't appear instantly, but I can summon the force quit menu and simply kill Opera, at which point the OS returns to normal.
However, there *is* _something_ confused, as my GPU is sitting at 6W and full boost, yet with no active processes. Seems to suggest that something is orphaned yet still running. I am now going to log out and back in to see if I can fix it without rebooting.
EDIT: fixed the 100% use, but not the power draw, by putting it to sleep and waking it back up. Interesting!
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?
Often there's shared resources that are statically allocated to shaders (register space, local memory etc.) that means you often can't "just" add a new task if those shared resources are already in use. But not using those resources to their full would cause performance issues.
And the internal state of a GPU is often very large, much larger than a CPU, so suspending the current tasks, saving out their state and replace it with a "higher priotity" one can be very expensive - so often an afterthought of support at best.
Otherwise GPUs typically do context "pre-emption" by basically being cooperative and just injecting yield statements in the command queue or on things like tile boundaries for tile based renderers. So the smallest chunk of work they can yield between ends up actually being quite large, and with a full user-supplied program in the middle
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.
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).
Wonder what made the difference. I must've disabled some shady JS attack surface at some point.
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)
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...
"termination" : {"flags":0,"indicator":"monitoring timed out for service","code":1,"namespace":"WATCHDOG","details":["(1 monitored services unresponsive): checkin with service: WindowServer (0 induced crashes) returned not alive with context:","is_alive_func returned unhealthy : 0x2|33130:33130:1|04000000:04000000:04000000 0x4|30324:30324:0|04000400:04000400:04000400 0x5|99275:99275:2|04000400:04000400:04000400","40 seconds since last successful checkin, 139478 total successful checkins since 1481204 seconds ago, has not exited since first loaded"]},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?
It is, but only when a big corp isn't doing it. X is allowed to deny you service without an account and Reddit is allowed to deny you service without uploading your personal documents to Persona.
Making the user force-reboot the computer would make the usual fake AV shtick a lot more believable.
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.
Being able to freeze a computer from the browser is a plain availability risk. It's not exactly a high-priority risk, but still something that should be considered a risk in my opinion.
With operating systems like macOS+Safari reopening a page after reboot, a malware domain can claim to take your computer hostage by te-freezing the PC every time the user moves away from the page until money is paid. People already fall for "we have hacked your computer pay X bitcoin to get it back", this just adds to that.
According to the comments here, this has been a thing for ages, so I kind of doubt that they'll fix it this time. But fingers crossed!
Worse and less defensible on the web of course.
A OpenGL ES 3.0 application without any issues, might be super slow when ported to run on WebGL 2.0.
How about the irrecoverable loss of data in RAM, though?
The funny thing is the page describing the problem stutters like crazy in firefox/mac while the rotating nuclear hazard wheel is displayed.
- macOS 14.7.3 (23H417)
- Chrome 152.0.7977.84
- Hardware: MacBookPro17,1 (Apple M1)It doesn't even need to be computationally difficult, you can also slam the memory bus with "far away" fetches that are randomly distributed, ensuring each fetch doesn't share a cache line with any surrounding fetches. There are popular UX effects with basically this workload, even, that's a naive implementation of a large radius gaussian blur basically...
A true scientist! (see https://xkcd.com/242/)
It's always funny to me when you put computers into such states. Last time I was tickled this was was when I nuked the TCC database permissions for Zoom while in a meeting, sharing my screen, using my microphone and camera. The OS rrrrreally didn't like that.
From https://news.ycombinator.com/newsguidelines.html:
"Don't be snarky."
"Edit out swipes."