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