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.
Since then, the world has changed… some design firms have transitioned to be purely marketers, others just hire development firms that are happy to defer all UX to their partners, and others still have transitioned to be UX/UI design firms.
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...
There are other scenarios that don't involve a ring-zero vulnerability but still result in a "reboot". Safari coordinates with other system processes, like the one that shows the home screen. If a web site can cause Safari to cause that process to crash, it would feel like a "reboot", even though no ring-zero code was attacked.
It's unintuitive to many people how many scenarios eventually allow a RCE exploit to be crafted. Check out some null pointer deref RCE's to convince yourself.
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...
I don't see a kernel panic there.
My understanding is this bug uses up GPU memory/contexts, not normal system RAM, and that’s why it becomes an issue.
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.
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.
Most people that call themselves security researchers will notify the vendor and give them some amount of time before publishing it. He waited 1 day.
My best guess is that since it's just a OS crash, he felt he could release it. But for something that is easy for any website to do, seems like he should have given them some more time.
can be related to AppleJPEGDriver-memleak [1]
[0] https://news.ycombinator.com/item?id=17998178 [1] https://github.com/bazad/AppleJPEGDriver-memleak
[1] https://trac.webkit.org/changeset/235475/webkit [2] https://bugs.webkit.org/show_bug.cgi?id=188504
I guess that restarting is less important than modifying memory it shouldn't.
Safari on MacOS is also affected, and you can make it persist with a little bit of JS.
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.
> DO NOT CLICK THE LINK! Hour later I am still unable to restart my phone. It hangs on logo!! This may be a permanent fuck ;(
Its truly awesome that you audited the whole Linux kernel and everything on top of it you run, mind sharing your notes?
There is nothing different about browsers than other apps, but given how they work people are far more likely to discover these kinds of bugs in browsers.
I’m no security researcher but, as I understand, it shouldn’t be exploitable if this is the case.
- 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
That's because the iPhone didn't reboot fully. This doesn't deterministically cause a panic, sometimes it just takes down parts of the system.
This is not to be confused with iOS unlock. SIM PINs are not commonly used in the USA.
It does. The memory allocation that causes the crash doesn't come from Safari, though: it's a memory allocation in the kernel (likely somewhere graphics related), and that counts towards XNU's memory consumption and not Safari's.
