This reminds me of how I was unemployed for a good chunk of the year 2001.

I was making a fresh start in a new city, and shopping my resumé to various graphics design firms. There was a prominent link to my portfolio site up top. After months of looking I didn’t get a single call-back.

Eventually I got a job in another industry, and noticed a bunch of Macs in the corner that they used for testing. One day I decided to load my portfolio site for fun... turned out there was a glitch in CSS support in Internet Explorer that would crash the browser, and since this was Mac OS “Classic”, that took down the entire machine.

Graphic design firms were all still on Macs with the old OS back in those days; I had been walking around crashing computers and destroying people’s work for months.

The tweet announcing it: https://twitter.com/pwnsdx/status/1040944750973595649

The code that causes the crash (safe to open): https://gist.github.com/pwnsdx/ce64de2760996a6c432f06d612e33...

The demo itself (causes crash): https://cdn.rawgit.com/pwnsdx/ce64de2760996a6c432f06d612e33a...

I have always wondered why Safari crashes can reboot the entire telephone. Doesn't iOS have multiple protection rings or is Safari running at ring 0? Or is it a precaution that inhibits jailbreak research?

I tried it on my iPhone X and it triggers a kernel panic (agxk_mmu.cpp) when trying to allocate memory for WebKit.

It seems it exhausts the memory so fast that it triggers an assertion error somewhere?

Screenshot: https://i.imgur.com/6tDr44q.png

Full serial console log of the device: https://gist.githubusercontent.com/KenanSulayman/867cc399e97...

This isn't just an iOS bug. The affected CSS property is just not available on most platforms.

Sinfe I do not have access to any apple hardware, I tried turning on the experimental web features in Chrome Canary on my phone and it managed to freeze Android as well. The Chrome browser crashed on Windows with this setting on. Microsoft Edge, the only browser other than Safari to have support this property without messing with config, just showed a generic "this page can not be displayed" message.

I think this problem affects the entire WebKit/Blink code base, the only reason the crashes are not being detected on other platforms is that most browsers just don't support this feature yet.

This is basically 3,485 nested <div>s (balanced; same number of </div>s) with width and height both set to 10,000px.

I have no idea is this is an internal DOM overflow or it's because of the tiled background-image. (I don't have an iPhone to test against.)

EDIT: I actually read the article properly :) all 3,485 the <divs> have a 10px backdrop-filter set on them.

> He explained that nesting a ton of elements — such as <div> tags — inside a backdrop filter property in CSS, you can use up all of the device’s resources and cause a kernel panic

Fun trivia: ^F for <div> on the GitHub gist page, and Chrome will inch... forward... so... very... slowly... finding... matches. You have to search the raw file if you want it to complete this century.

It also gets my Macbook Pro in an unresponsive state (using Safari).

Don't most security researchers wait until it is patched before posting the details of something like this?

I am guessing from the log posted [0] this can be some kernel memory leak.

can be related to AppleJPEGDriver-memleak [1]

[0] https://news.ycombinator.com/item?id=17998178 [1] https://github.com/bazad/AppleJPEGDriver-memleak

Dug through WebKit Bugzilla and Trac and the only recent visible "crash backdrop" issue seems to be "Fix crash when reflections and backdrop filter are combined" [1], which references bug that requires authorization [2].

[1] https://trac.webkit.org/changeset/235475/webkit [2] https://bugs.webkit.org/show_bug.cgi?id=188504

Reminds me of a Safari memory leak issue I stumbled upon two years ago: https://stackoverflow.com/questions/35782231/why-is-a-safari...

I guess that restarting is less important than modifying memory it shouldn't.

More details about the attack in this interview with the researcher: https://www.zdnet.com/article/nasty-piece-of-css-code-crashe...

Safari on MacOS is also affected, and you can make it persist with a little bit of JS.

I sent to a colleague, and the iPhone didn't reboot.... It got crashed, and she had to use itunes to recover. Be careful....

It’s cruel of them to make this discovery public without a fix.

Thousands upon thousands of normal, non-tech, non-fanatic people are going to be sent a link to this page by someone mean who wants to crash their phone and laugh at their pain as they’re locked out of their life by a crash bug.

This is irresponsible disclosure.

I have tried it on a iPad Mini with iOS 8.4 (jailbroken) and it does nothing.

I've stopped accepting iOS/OSX seriously after those iCloud celebs leaks and especially after 'empty string' root prompt bug. How anyone can still trust this black box concept.

How is it that browserland always seems to impact the OS? Is it the browser's need for graphics drivers? Or are these browsers embedded at a different level compared to a traditional OS?

Can anyone confirm if this is a denial-of-service attack (through memory exhaustion)?

I’m no security researcher but, as I understand, it shouldn’t be exploitable if this is the case.

Can't wait for the supplemental update for this (I doubt they have time to revise the GM releases for watchOS and iOS but maybe they can fix Mojave.).

From the twitter thread

- This is a full kernel panic; I wonder if it's exploitable (...probably not)

- Someone's iPhone didn't ask for their PIN on reboot?

- It apparently crashes watchOS 5 too

Is this due to memory exhaustion? If so, does Safari not have limits applied that cause it to be killed for running into OOM?

It also stalled my iMac on Safari 11.1.2, macOS 10.13.6. Had to force reboot.

Tested in on my Macbook in Safari, it crashed spectacularly

Works on Safari either on the iPhone or iMac/Macbook.

Here's a JS-based attack that will freeze Chrome/ChromeOS, by the same person: https://twitter.com/pwnsdx/status/1038821975089664001

I take it some Apple engineers were/will be called in on a Sunday in order to push a WebKit / Mobile Safari "11.4.2" security update. Thoughts, prayers and coffee.