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.
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.