A new CSS-based web attack will crash and restart your iPhone
techcrunch.comThis 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.
In my first commercial attempt at web development I utilised a png transparency fix for IE6 (written in that IE6 specific filter thing). A few months later the client passed on a complaint from one of his customers whom's machine crashed whenever he visited the website... I removed the IE6 fix and all was well in the world - You can have nice things or MS, you can't have both.
I think MS is doing a pretty decent job of trying to repair that. Especially with developers.
Is the new industry you are working in penetration testing?
On the bright side, you are probably making 2-4x the salary of a graphic designer in today's market if you learned to code...
I knew how to code in the first place. At the time, I was dismayed by the inability for most software developers to take UX/UI seriously, and decided that "the way forward" was to work with design professionals instead of being inside a party that was ostensibly on the same team but usually fought against designers.
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 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...
Haha! Looks like another modern version of zip-bomb[0] or should I say - div-bomb:)
Interesting, it's simply a few thousand nested divs with a huge blur on them. Is it something specific about blur? Or could you do the same thing with box-shadows, etc, if there are enough of them?
-webkit-backdrop-filter forces layerization (i.e. it promotes whatever box it's in to a Core Animation layer), while box shadows don't. This resource exhaustion bug is specific to CA layers, so you wouldn't see this with box shadows.
Works on iPhone SE w/ iOS 12 latest public beta.
Worked on iOS 11.4 iPhone 8
It works!
I clicked the third link thinking it was a link to a demo video. I can confirm that 1) it’s not a link to a demo video 2) it rebooted my iPad.
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 ;( unsure exact version but I have iOS 7 that hasnt been updated in about six months.
If you use iCloud for Safari, you can close another device's Safari tab from your Mac. click the iCloud tabs icon on desktop Safari, then click the circle-x to close the offending tab.
This is a great suggestion for those stuck on this crash
Seems like on restart Safari wants to revisit previously opened pages and crashes again ad infinitum. Isn't there a way to cold-restart iOS devices or some such (like the magic "Zap NVRAM and repair permissions" procedure back in PowerMac times)?
"Seems like on restart Safari wants to revisit previously opened pages"
I've always found that behavior annoying. If I want to revisit the last page, I can find it in history.
I'm sure you're in the absolute minority. Most people want all apps, including the browser, to stay the way they were when they closed them, even after a reboot
I sure as heck want my tabs back. But I'd settle for "restore tabs" as I have to do that a lot in chrome on my MacBook Pro. On my Android, the tabs are just there and I really appreciate it. I have over a dozen tabs open on my phone and two dozen on my laptop.
It’s very convenient, but isn’t that scenario better covered by hibernating the os? That covers all app and doesn’t require any app to have special behaviour coded in
If I never had to restart, sure. I have to restart my laptop weekly at least. Heck, it locked up twice last week opening Diablo 3 forcing a hard power cycle. My phone gets restarted less often but still gets into odd states where a reboot is needed.
tangential, but check out that your power supply is ok, that's the second most common source of random lockups during load (I assume drivers are up to date, that'd be the first)
Me too. I want a blank page when I open my browser. If I reboot a device, I want nothing but base system running when it restarts.
But that’s why you need a “safe start mode” where you can start the app with a clean slate. Several Microsoft Office apps do this now. Given iOS’s repeated “crash loop” issues you’d think they’d have learnt by now.
I'm in that minority too, I guess. There's nothing more grating than to explicitly close all tabs, only to be asked whether you want to open them again. For me, tabs are like this useless plaque that slowly accumulates and needs to be blown away every two or three days.
Yep. I know someone who keeps dozens and dozens of tabs open on an iPhone. It's kind of like a bookmark library.
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.
That always bothers me. What if a page was (dumbly) in a state that makes a change I don't want?
Do you have data for this? I'm also in the absolute minority
try a force restart (home + power button for about 10 seconds)
What is home?
It's the name of the round button at the bottom of the iPhones without Face ID.
I think he meant hold down volume down + power button for 10 seconds.
Older iPhones with physical home button use that for restart.
Last year’s model.
Last year’s iPhones 8 use volume down + power for restart because home is not a button, but a sensor and it has to be powered to work.
there's no iOS 7 device without home button :)
No hang on 11.4.1. It came back fine.
Able to reboot fine on iOS 12 after the crash. Safari didn’t try to reopen closed windows as well.
DO NOT CLICK THE LINK!
Never imagined I'd read those words at HN. How times have changed. Be sensible people.
More details from the Twitter thread: it's iOS 7 and up, and it also works on watchOS 5. In some apps like chrome or opera it isn't a full crash, just a "springboard crash".
I always said iOS 7 was a disaster. iOS 6- opened 8 tabs at most (deleting old tabs) and no one complained. These new youngster oses can not even manage memory in a right way — now with all these GCs no one knows how to do it.
For me it just closes the Hacker News app. No reboot.
The Hacker News app??
I assume that he means one of the many Hacker News clients available for iOS such as MiniHack [1] or Simple Reader for Hacker News [2].
[1] https://itunes.apple.com/it/app/minihack-hacker-news-client/...
[2] https://itunes.apple.com/us/app/simple-reader-for-hacker-new...
I think he means the web browser app. Probably only used for Hacker News. Like a boss.
works on iOS 12 GM also
I wonder if they are trying to fix it before tomorrow’s release.
It is more likely that they would fix this in a 12.0.1 that will be available shortly than to change the 12 release as all new iPhones come preloaded with 12.
Survivorship bias
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?
Safari does not run at ring zero. However, it can make system calls into the ring-zero kernel and drivers. If there's a bug in the kernel or drivers, that can cause the kernel to crash.
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.
This is a kernel panic, as per the twitter thread.
One of the older iOS jailbreaks, written by comex, was launched via Safari. It generally takes a few vulnerabilities to get to arbitrary code execution in the kernel. You have to (1) break out of the browser sandbox and (2) defeat exploit mitigation technology, such as non-executable stack and finally (3) escalate privileges. There can be some potential shortcuts to this, but that is the basic sketch. Why multiple vulns? To defeat ASLR, for example, you need something that leaks information about how the memory is layed out. This also helps defeat NX (non-executable stack) as you use existing code to do the initial bootstrapping of your exploit.
It's prudent to reboot when a privileged component crashes, since the integrity of the code execution has been compromised. A lot of the time a DoS bug in native code is synonymous with "nobody bothered to craft a RCE".
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.
That may be true, but it's unrelated to what's happening here. If you've ever seen a "there was a problem with this page" bar appear, that was a Safari process crashing without bringing down the system (or even the browser UI process). The crash here is happening at a lower level.
But why is Safari a privileged component?
Just to clarify the situation:
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 :)
To explain to other readers: JIT processes usually have to violate the standard W^X protection rule for memory pages by either simultaneously mapping them to both data and code virtual pages, or remapping them before&after JIT compilation. I'd hope it's the latter. JITs are basically compiler-linkers directly to memory, so need to have their output transformed from data pages into code page in order for it to be executable.
Safari does MAP_JIT, I believe, so it keeps around RWX pages (edit: I think just one page). The best third-party apps can do (on non-jailbroken devices) is W^X–that is, map memory as RW, put code on it, then remap it as RX–because they cannot gain the dynamic-codesigning entitlement. Even this requires jumping through hoops, such as its own set of entitlements and specific setup dance, which makes it not available to App Store apps.
Because web browsers are trying to sandbox executable code from untrusted (and frequently malicious) sources, I would guess. WebKit/Nitro are trusted to keep that executable memory under very tight control, and if they're crashing they may have failed to.
IIRC it has special privileges that allow it to run a JIT javascript engine.
It remains disturbing to read that something needs to be privileged just so it can sandbox unprivileged code. Why should I have to choose between trusting the sandbox and trusting the code that runs inside it? Why do we keep collectively forgetting the lesson that the more useful a sandboxing technology becomes, the more likely it becomes that someone will need to run that sandbox inside another sandbox (or inside another instance of the same sandbox)?
> It remains disturbing to read that something needs to be privileged just so it can sandbox unprivileged code.
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.
It doesn’t need privileges to sandbox unprivileged code. It needs special permission to run a JIT because that implies running binary code that was compiled ‘Just In Time’ on the device, so it isn’t signed.
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.
Safari still only runs as a low privileged user named “mobile”. Check out pwn2own and other previous full Safari to kernel exploits. It has always taken multiple bugs to get to the kernel for a number of reasons. This thing could be doing all of that, but bugs that legit exploit and crash the kernel are quite valuable and at a minimum jailbreak teams care a lot about bugs (sets of bugs, really) that do this! The author may have been fuzzing and found a true one bug DoS that has no utility beyond crashing Safari. They may not be aware of how cool what they found is, also. Regardless once it becomes public the hole is burned and Apple will fix it. Oh and th mobile user is sandboxes too. Apple has a thing called Seatbelt, check it out.
It's not privileged in that it can sandbox unprivileged code, it's privileged in that it can run that code at all. Other processes are not allowed to execute writeable memory.
MobileSafari has a special "dynamic-codesigning" sandbox entitlement that allows the JIT to function.
This is the correct answer.
The reason is because security in the real world will never be pure or without defect. The goal is not to create perfectly secure software, it’s to minimize risk to an acceptable level.
Because it JITs Javascript code. That code comes in as data. So it has the power to override W^X.
The author said in the twitter thread that this a kernel panic.
Safari on iOS reminds me of Windows 95 and Active Desktop. Whenever IE crashed, it took the entire shell (explorer.exe) down with it.
It also crashes chrome on iphone.
The underlying browser for chrome on iOS is still safari. The same is true for every other browser.
Which is weird though, I had a few sites not render properly on Edge on iOS but did on Safari. Some kind of compatibility mode?
...however Chrome does not have the same privileges to run accelerated js on iOS that Safari does. Interestingly though this attack has nothing to do with javascript.
If they finally switched from the deprecated UIWebView to WKWebView, then chrome too gets to run JS at safari's speed. WKWebView runs out of process and thus can have the JIT entitlements.
That’s not how it works...
Is not chrome just wrapper on iPhone ?
Same here, I thought it was completely sandb0xed
A completely sandboxes process can do nothing, since doing anything from a network request to drawing to the screen requires cooperation from the OS. Safari is partially sandboxed, just like any other app.
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...
The log suggests the device is doing everything correctly. The exploit webpage requires huge amounts of memory to render correctly. It is consuming all the available memory causing allocations for backboardd to fail. The kernel then starts killing off idle processes to free up memory.
I don't see a kernel panic there.
Does iOS not enforce reasonable memory limits on apps to prevent a panic?
It does. Your app will get killed. The OS will be fine.
My understanding is this bug uses up GPU memory/contexts, not normal system RAM, and that’s why it becomes an issue.
Ahh thank you :)
Ohh.. sneaky: a GPU DoS.
Yeah. Of course it shouldn’t be possible, but I guess no one had thought of it before or they thought the risk was too low because they figured you’d have to make an app to do it not some random HTML on a webpage.
Have you tried the backdoor yet? https://www.gnu.org/proprietary/malware-apple.html#back-door...
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's because of the nested backdrop-filters being applied. I would've thought the css parser / rendering engine stops this from happening, but apparently not.
I guess it is because backdrop-filter is a new property. AFAIK backdrop-filter affects everything everything below it, so maybe a sanity check for the number of times the effect applies is missing.
Yeah it looks like its trying to compute thousands of filters stacked on top of each other. Photoshop would take a while to do that too. But safari shouldn’t be able to out of memory so hard it takes down the device.
It also gets my Macbook Pro in an unresponsive state (using Safari).
Copy that. I had to hard reset. (No crash while using Firefox, Chrome & Vivaldi).
Those browsers don’t support those CSS filters yet, you’d have to do chrome canary for example. Another poster tested with the features enabled and got the same crash.
Don't most security researchers wait until it is patched before posting the details of something like this?
Why the downvotes? The guy is a security research, and published a bug that can crash the app or OS (reports in this thread have reported mixed results, and others are saying it may impact OSX as well). The guy goes to Twitter the announce the bug.
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.
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.
Rebooting phone doesn't look like a tragedy.
https://news.ycombinator.com/item?id=17997958
> 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 ;(
I have tried it on a iPad Mini with iOS 8.4 (jailbroken) and it does nothing.
It doesn't crash for me either on iPhone 5 / iOS 8.4.1. It just renders a long webpage.
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.
Weren't those phishing compromises?
They were. OP seems to have bought into the fake story that someone legitimately hacked iCloud and only made it out with photographs.
Root and empty password was a macOS issue: https://twitter.com/lemiorhan/status/935578694541770752
So what do you trust? Google?
Linux and its maintainers. LineageOS and its maintainers.
> How anyone can still trust this black box concept
Its truly awesome that you audited the whole Linux kernel and everything on top of it you run, mind sharing your notes?
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?
What other apps do you have on your phone that are executing what is essentially an enormous amount of untrusted code?
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.
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.
DoS of safari or the kernel? It's a kernel panic, which is not a safari dos; no user space app should be allowed to crash the kernel. Memory exhaustion should just trigger an OOM kill at worst.
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
> Someone's iPhone didn't ask for their PIN on reboot?
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.
It didn’t ask for their sim PIN, which is expected if the sim does not lose power, like in a full reboot without power off (eg kernel panic auto restart).
This is not to be confused with iOS unlock. SIM PINs are not commonly used in the USA.
Some reboots on iPhone (including if you force it yourself by holding HOME + Power on iPhone 6) don't relock the SIM card, so that might be the "PIN" that was missing.
Is this due to memory exhaustion? If so, does Safari not have limits applied that cause it to be killed for running into OOM?
> If so, does Safari not have limits applied that cause it to be killed for running into OOM?
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.
Ahh thank you!
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
Chrome performs similarly, if the flag enabling 'backdrop-filter' support is set.
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.