Busted. My browser is configured to do just that.
The Deathray: A simple way for an untrusted site to freeze a Mac (auberon.xyz)
186 pointsby auberonedu14 hours ago111 comments
isolay an hour ago
> Just hope that your browser doesn't automatically reopen the same tab when it starts up again
concinds 14 minutes ago
Chrome asks whether to reopen windows if it didn't exit normally. Safari just YOLO's it. Don't know about Firefox.
amelius 8 minutes ago
Unplug your ethernet cable?
washadjeffmad 7 hours ago
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.
r3trohack3r 7 hours ago
Were there multiple of these sites?
If not, I have fond memories of using yours!
Matheus28 5 hours ago
I remember when `alert` would lock up the entire browser UI. So if you put it on an infinite loop, that was it. You had to kill the browser process to shut it off.
parl_match 5 hours ago
there was a common "shock site" called "last measure" that did this. it loaded all sorts of offensive images, blasted a loop of a guy yelling something offensive about pornography, and then proceded to lock up your machine.
davkan 5 hours ago
Oh man I had forgotten about last measure. I remember multiple times scrambling for the power button.
QuantumNomad_ 2 hours ago
And also the more innocent “You Are An Idiot, hahaha hahaha” page that would sing those words and spam pop up windows with white and black text blinking, that would float around the screen. Every time you click close on one window, two new ones pop up.
With that one, Ctrl+Alt+Delete, Task Manager, kill iexplore.exe was usually all you needed to do thankfully. No hard power off necessary.
amatecha 2 hours ago
I was just talking about that one with someone a few days ago! Amazing hahah XD I still remember the song and was singing it while laughing profusely at how obnoxious that site was!
socalgal2 4 hours ago
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.
zelphirkalt 3 hours ago
Do you think a regular user knows how to block a specific website or never click a link leading to it again? And what about the ads people, adding such a thing if you don't load their ads?
I think this point of view is making it a bit too easy.
socalgal2 3 hours ago
A user doesn't need to know anything other than "when I go to site XYZ.com my computer freezes. Guess I won't go there again"
> 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.
chrisjj 2 hours ago
> A user doesn't need to know anything other than "when I go to site XYZ.com my computer freezes.
Not true, given any unknown link or button press can redirect/go to such a site.
xingped 2 hours ago
I think a lot of HN commenters are way too disconnected from the average person. You're making a big assumption that a user will even connect the dots until the same thing happens multiple times, if even then. The average computer user is extremely bad at connecting cause and effect on their computer. Think of how many times you hear "my computer is broken!" when actually it's something like the printer was unplugged/turned off and they were just having trouble printing a document (or, if you are so disconnected from average users/people, the answer is _this happens a lot_). Even what we think of as simple stuff completely befuddles them.
DrewADesign 18 minutes ago
> I think a lot of HN commenters are way too disconnected from the average person
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.
sersi an hour ago
An average user will not know that the site caused the issue. The first time after force turning off the computer, it will restart and reopen all windows causing the computer to crash again. The next time, they might click on the button to prevent reopening all windows and everything will be fine until they opens safari which will cause the same issue. At that point, they'll call whoever is their computer expert user to help them out.
StilesCrisis 9 hours ago
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)
gucci-on-fleek 5 hours ago
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.
alwaysmrno an hour ago
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.
xoa 9 hours ago
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?
StilesCrisis 9 hours ago
With Chromebooks, Chrome is in fact put in the position of being a real operating system and is the only surface exposing the hardware's capabilities!
autoexec 9 hours ago
I'm with you. WebGPU has been used to compromise and fingerprint systems. Firefox (and related forks) are usually able to disable this kind of insecure fluff but it'd be nice if other browsers did as well.
mh- 9 hours ago
On the other hand, disabling WebGPU is offering entropy for fingerprinting, too. A vanishingly small % of users will have done so.
autoexec 9 hours ago
True, but randomizing other data points will keep your fingerprint unique which should help prevent associating your activity across sites/sessions.
seany 9 hours ago
don't some of the adblock extensions randomly modify the fingerprinting you can get from this?
autoexec 8 hours ago
Hopefully, but it's good to have it disabled as well so that your system isn't screwed by the next zero day and to help cover you in case the fingerprinters manage to find a technique to get identifying data from WebGPU that your ad-blocker hasn't accounted for. It's a constant arms race after all. Hopefully the ad-blocker is still feeding them randomized data even with it disabled, but otherwise other randomized data points should keep your fingerprint unique even if a lack of WebGPU support stays consistent.
xoa 8 hours ago
>On the other hand, disabling WebGPU is offering entropy for fingerprinting, too. A vanishingly small % of users will have done so.
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.
socalgal2 4 hours ago
WebGPU provides ZERO extra data that wasn't already available from WebGL in 2011. The world didn't end and it's been 15 years
Razengan 30 minutes ago
> The world didn't end and it's been 15 years
Maybe it did and you're just hooked up to the Matrix thinking it didn't
stackghost 9 hours ago
Quite so. When it first took off, I took no end of flames and downvotes for suggesting that WebGPU is a terrible idea. HTML and the browser were originally conceived to render documents, not serve as a bastardized application distribution platform.
The 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.
lmz 8 hours ago
The BigCos are the reason you have that browser in the first place. If you don't like it, you know where to download ... links or something.
stackghost 8 hours ago
Hey you’re right, we should gladly accept every decision the big corps make. They know best, after all. We should probably lick their boots too, in gratitude for their benevolence.
lmz 8 hours ago
The application delivery thing was done as far back as Netscape threatening to relegate Windows to "a poorly debugged set of device drivers" so Web-whatever is simply another step in that direction. Like I said, if you purists want just document delivery, you can use links or w3m or maybe Gemini.
mitxela 6 hours ago
Some kind of market forces kept Netscape in check back then. Now they aren't.
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?
Melonai 4 hours ago
Yeah in the end I probably agree on WebGPU, I haven't really seen a single use of it, except for running shader code examples in browser, which might as well be replaced by a looping video.
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.
userbinator 7 hours ago
WebGPU/WebGL is another thing that only trusted sites should be allowed to use, just like JS in general.
varenc 7 hours ago
> notice they have a dom.webgpu.blocked-domains with the sole entries being "easyeda.com,*.easyeda.com", I wonder what that's about?
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.
ruined 3 hours ago
incredibly, the underlying issue seems to be lack of support for shadowing built-ins and reserved keywords
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
monster_truck 10 hours ago
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.
LoganDark 10 hours ago
Kinda reminds me of that wifi network with a funky name from Doctor Who that gets you uploaded to the cloud. (episode: The Bells of Saint John)
tetrahedon 4 hours ago
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.
socalgal2 4 hours ago
that's because they don't hav any security relevance.
ta8903 3 hours ago
most bugs don't
john_owl an hour ago
I was lucky, the website is down due a certificate error.
slicendice 10 hours ago
I want to click it so bad, but I can't bring myself to do it.
LoganDark 10 hours ago
For me it just caused Safari to stop working until I quit and restarted it.
embedding-shape 9 hours ago
A Denial of Browsing attack.
LoganDark 9 hours ago
I have two other web browsers open at any given time, so probably not really. I guess it would be if it truly did bring down the entire system.
bittercynic 9 hours ago
On my M1 MacBook Air with MacOS 12 it hangs. The mouse pointer still moves, but I can't bring up the force quit dialogue, and couldn't get anything else to work either. A youtube video in another tab kept playing until I held the power button to force a shutdown.
LoganDark 9 hours ago
I'm using macOS 27.0 RC on M4 Max
willio58 9 hours ago
After a long day at work I saw the page, saw the warning to not click it, and I proceeded to click it lol.
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?"
12_throw_away 9 hours ago
honestly i bet it feels good as fuck to click on malware, just once
navtoj 8 hours ago
I tried it on macOS Sequoia and it froze everything except the cursor movement.
davsti4 7 hours ago
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)
SugarReflex 9 hours ago
On a Windows 11 work machine - this is causing my Teams to blink black and come back randomly. Yes I used my work machine.
wzdd 4 hours ago
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.
krackers 9 hours ago
>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?
kimixa 9 hours ago
Often not in the same way - even if there are multiple queues (that can be given a priority), they're often limited in what they can schedule between.
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.
mitxela 6 hours ago
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?
kg 5 hours ago
Historically, for loops in shaders were limited in the number of iterations they could run for. Among other things this ensures that rasterizing a particular pixel completes in a known amount of time (and ideally that amount of time is fast enough to avoid triggering TDR on windows and making the machine bluescreen). You could of course nest loops so it's not a perfect measure. I'm not certain whether that limitation applies to WebGPU, but it should apply to WebGL.
mitxela 3 hours ago
Historically this was because GPUs didn't have control flow and the compiler had to fully unroll the loop. Once that was lifted, you could have any condition and were only limited by a timeout.
auberonedu 5 hours ago
In my testing, a looping compute shader was enough to crash the tab on its own, but it needed waiting render shaders to crash the WindowServer.
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.
nottorp 2 hours ago
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.
eliwang 6 hours ago
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.
germandiago 2 hours ago
Thank you. I was tempted to press but I was afraid of making a mess. I won't.
sgentle 10 hours ago
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?
mitxela 6 hours ago
> Is denial of service not a security thing any more?
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.
code_duck 4 hours ago
That’s not what denial of service is.
thin_carapace 4 hours ago
what about when big companies drown the web with crawling activity, forcing webmasters to implement fingerprinting and thus massively delaying actual users from accessing webpages that would otherwise load instantly?
mitxela 4 hours ago
denial of service is when service is denied
ilnmtlbnm 14 hours ago
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...
TedDoesntTalk 10 hours ago
Is this why Oregon Trail Deluxe freezes on Mac?
splittydev 8 hours ago
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.
xcc3641 6 hours ago
Does this reproduce with just the compute pass, or does WindowServer deadlock on the canvas drawable?
auberonedu 5 hours ago
itstrueitried 10 hours ago
while (true) console.log('this will freeze/crash dev tools')
anakaine 9 hours ago
Shall we term this a Denial of Memory attack. Then in order to Contain it we have a ConDoM fix?
LoganDark 9 hours ago
This doesn't even always work unless you log two different messages, because some DevTools will just keep a running count of how many of the same message there has been in a row.
yesitdoes22 9 hours ago
fwiw it froze my tab in seconds just pasting that into dev tools
LoganDark 8 hours ago
I think running it in the DevTools console is different from having a script on the page.
yesitdoes22 6 hours ago
No actually. The only reason it crashes in dev tools is that it is rendering the printed console log.
If you printed to some div in the page, you will get the same effect.
Do you understand the topic? Doesn't seem like it
LoganDark 4 hours ago
> Do you understand the topic? Doesn't seem like it
Since you are so polite I tested all of it just now and it turns out you are correct that running it directly from the devtools console does not cause any worse behavior than running it from a normal script tag.
However indeed logging only a single message simply causes it to be combined and show a counter instead of crashing. Logging two different messages causes the log to explode pretty instantly and hang DevTools fairly quickly.
For context on how not-crashy a single message log was, I was able to navigate to the Sources tab and pause the webpage in the middle of its infinite loop, which is not something you should be able to do if the DevTools are truly overwhelmed. (When that happens, sometimes the Sources tab simply does not load, other times trying to pause execution simply does nothing.)
chrisjj 2 hours ago
> recoverable data loss which we do not consider to be a security issue
How about the irrecoverable loss of data in RAM, though?