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.
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 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.
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.
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.
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)?
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)
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.
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.
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.
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.
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.
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.
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.
...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.
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.
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.
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.
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.
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.
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.
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].
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.
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.
We've banned this account for repeatedly breaking the site guidelines. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future.
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.
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.
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.
> 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.
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.
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.