A new CSS-based web attack will crash and restart your iPhone(techcrunch.com) |
A new CSS-based web attack will crash and restart your iPhone(techcrunch.com) |
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...
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.
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.
[1] https://itunes.apple.com/it/app/minihack-hacker-news-client/...
[2] https://itunes.apple.com/us/app/simple-reader-for-hacker-new...
fulafel’s comment (parent^4 of this comment) is incorrect. iOS does not automatically reboot when Safari or WebProcess crashes, and Safari is not generally treated as a ‘privileged component’ overall – to the contrary, last I checked it had a tighter sandbox than most apps.
As people have noted, Safari does have special privileges to run a JIT, which is otherwise restricted. This is not because running a JIT can compromise the security of the system as a whole, but simply because having a JIT in your process makes it easier to exploit that process, making it best to avoid except where absolutely necessary.
By the way, I haven’t looked into this crash myself, but my guess is that it’s an unexploitable out-of-memory situation. This would still involve some sort of bug in the kernel, since it shouldn’t be possible for a process to take down the whole system (especially not ‘by accident’). But in general it’s relatively common to have bugs where you can make a more privileged piece of code run out of memory, and most of the time there’s no way to turn them into code execution. Of course, “most of the time” != always, and there’s no way to know for sure without tracking down the root cause :)
IIRC it has special privileges that allow it to run a JIT javascript engine.
That's not what is happening.
All modern JavaScript implementations use JIT for performance reasons. It's one of the main reasons behind the massive performance increases JavaScript has made in recent years.
JIT requires that the process be able to generate data then execute it as code. This is, historically, something that has been used in many security attacks. So modern CPUs provide the ability to stop this from happening (the NX bit).
iOS sensibly switches this off by default. Which is fine in most cases, but in some situations – like JavaScript JIT – it's necessary, so Apple grant special privileges to the WebKit process (not Safari) in order for it to perform well. This is part of the reason why the WebKit rendering happens in an external process – partly because it reduces the amount of code that needs this special privilege, and partly so that other applications apart from Safari can also get the JIT performance improvements without having to trust them with the special privileges.
There's no indication that this crasher has anything to do with Safari having special privileges, and I think it's likely that other applications can do this too.
Normal processes can only run binary code that was verified to be signed. They can’t write to memory and then mark it as executable.
MobileSafari has a special "dynamic-codesigning" sandbox entitlement that allows the JIT to function.
I've always found that behavior annoying. If I want to revisit the last page, I can find it in history.
Never imagined I'd read those words at HN. How times have changed. Be sensible people.
I explained that there is a bookmark feature just for this sort of thing, but when you're used to doing something one way, change can be slow.
