[fulafel]

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.

[panic]

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.

[jstanley]

But why is Safari a privileged component?

[comex]

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 :)

[swingline-747]

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.

[saagarjha]

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.

[wlesieutre]

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.

[anderskaseorg]

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)?

[JimDabell]

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

[tinus_hn]

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.

[bitexploder]

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.

[wlesieutre]

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.

[3chelon]

This is the correct answer.

[speedplane]

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.

[doctorpangloss]

Because it JITs Javascript code. That code comes in as data. So it has the power to override W^X.

[exikyut]

The author said in the twitter thread that this a kernel panic.