About a month ago, I had opened Chromium bug reports explaining this, informing them that a single page can crash a whole browser, but they... seem to have not really cared, so Chromium is okay with it, thus this cannot be considered illegal or malicious, as the developers don't care.
As of today, September 9th, Chromium finally acknowledged this bug and successfully replicated it, meaning the bug should be fixed within the year.
They don't care, they closed the report.
But... many factors come into play:
- Page size: large pages load slower, thus they reload slower too, if it's too slow, it's completely ineffective, although annoying.
- Loading speed: Related to the previous point, but there is more to loading than size, and HTML is just slow to parse in general, especially poorly designed HTML.
- Execution speed: There are a few micro-optimizations that can be applied to improve the performance of the loop.
So, how do you beat all 3?
CSS: A style-less page will load faster than one with style, so I cut it out.
Loading speed: Cut out everything unnecessary for a basic webpage to test the crash. HTML is slow to parse, so I used XHTML instead. Lastly, the page has no external data to fetch, it's all in one page.
Execution speed: There's much that can be done to improve speed here:
- Simply opting into "strict mode" improves performance noticeably.
An example of what we could use:
This is straightforward and simple, but... it's not at it's best.
refresh takes a boolean argument determining whether or not to reload from the server or cache, true indicating that it should load from the server.
As we used
location.refresh, we kept doing a method lookup, directly binding to the function would be better.
Unfortunately, reload exists on the prototype of the
Location class, it requires the
this of the location object, so it needs to be bound, put together:
Very similar, yet what difference is there? It's faster in every way, that's it.
Now, why would you use this webpage? Maybe you want to redirect specific users from a specific URL on your server to it? ¯\_(ツ)_/¯
Go check the source, run the page, have fun!
Report this to your browser vendor
I have already opened a Chromium report regarding this bug myself.
If you are on another browser, ex: Firefox, Safari, Edge, Opera, and this works, please report it to them as appropriate.
This bug is very annoying, I have personally opened the page too many times while developing it, and it almost crashed my low RAM computer :)
You don't need to exploit a bug, you can just fork bomb with web workers:
It makes your RAM usage skyrocket to 97%.
Also, there's a related bug report on Firefox's Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=537527.
@programmeruser On FF, it's just a memory problem with allocating a bunch of Worker objects and associated JSRuntimes, on Chrome I expect an actual fork bomb.
Oh, in that case, when Wasm gets access to threads, fork bombing will be fun!
I'll make a whole new post, not unlike the current one that we're on, but using CSS, and link you to it.
@xxpertHacker I think I found a claim code that crashes Replit; could you test it so that I can make sure that it isn't just a problem on my side?
Make sure to wait a bit, then try resizing the window or clicking a button in the sidebar.
@CodeLongAndPros Honestly, when I first talked about trying to post this, I thought that it would've been removed by the moderators, but then I laughed when I saw a mod upvote it.
Also, @Jasperscode this isn't even malicious. You need to see other Repl types; they force the web page to open here, so you would've already been attacked. At least you have to actually open the HTML Repls.
@CodeLongAndPros I barely remembered that I had asked, but I doubted that you would've remembered either, it was some time ago.
@Jasperscode This shouldn't have affected GPU usage at all :/
Any good CPU ought to be able to handle this.
Lastly, I've used an old Windows 7 and it nearly crashed the PC, but the hardware was perfectly fine.
for some reason this didnt crash firefox on ubuntu but i closed a window and it was still running so i had to restart my pc
@DungeonMaster00 Oh, you're lucky, it crashed quite a few other people, including myself (more than once).
Some browsers it won't work on at all (eg: Safari), and practically all mobile browsers, since they simply don't support running that webpage properly.
Also, why didn't you try using a task manager or something similar, if you hadn't crashed?
I wouldn't recommend trying this on Firefox on Mac. I tried it, and now I can't get it unfrozen (deleting and reinstalling, rebooting). Nothing seems to work. Good thing is that I don't use firefox.
It froze my Chromebook for about 5 to 10 minutes! I had to shut it down for it to work again!
thus this cannot be considered illegal or malicious, as the developers don't care.
Ah yes, so I presume finding a security flaw in Windows and making a virus that exploits it is perfectly fine then?
Jokes aside, this is a nice find. It's incredible that this hasn't been patched yet, as it seems way too simple of a bug to use.
@SixBeeps This is honestly the simplest bug I've spotted in a browser to date; I've seen people carefully thinking things outdoing some weird complicated stuff, carefully timing everything, etc, but this... it's effortless and surprisingly powerful, but it doesn't do too much, I can't steal your data or something.
But yeah I seriously did report it and they don't seem to care, someone might want to test if it affects Firefox, Safari, etc, and report it to them as appropriate.