5 ms·

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

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?

valleyer 8y ago
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.
- exikyut 8y ago
  This is a kernel panic, as per the twitter thread.
fulafel 8y ago
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.
- jstanley 8y ago
  But why is Safari a privileged component?
  - wlesieutre 8y ago
    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 8y ago
      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)?
      - speedplane 8y ago
        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.
      - tinus_hn 8y ago
        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.
      - JimDabell 8y ago
        > 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.
  - doctorpangloss 8y ago
    Because it JITs Javascript code. That code comes in as data. So it has the power to override W^X.
  - comex 8y ago
    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 8y ago
      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 8y ago
        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.
- exikyut 8y ago
  The author said in the twitter thread that this a kernel panic.
- panic 8y ago
  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.
avip 8y ago
It also crashes chrome on iphone.
- ben-schaaf 8y ago
  The underlying browser for chrome on iOS is still safari. The same is true for every other browser.
  - sneak 8y ago
    ...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.
    - aaaaaaaaaab 8y ago
      That’s not how it works...
    - pilif 8y ago
      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.
  - sebazzz 8y ago
    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?
- iamgopal 8y ago
  Is not chrome just wrapper on iPhone ?
howdydoo 8y ago
Safari on iOS reminds me of Windows 95 and Active Desktop. Whenever IE crashed, it took the entire shell (explorer.exe) down with it.
bitexploder 8y ago
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.
qrbLPHiKpiux 8y ago
Same here, I thought it was completely sandb0xed
- saagarjha 8y ago
  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.

valleyer 8y ago

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.

exikyut 8y ago
This is a kernel panic, as per the twitter thread.

fulafel 8y ago

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.

jstanley 8y ago
But why is Safari a privileged component?
- wlesieutre 8y ago
  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 8y ago
    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)?
    - speedplane 8y ago
      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.
    - tinus_hn 8y ago
      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.
    - JimDabell 8y ago
      > 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.
- doctorpangloss 8y ago
  Because it JITs Javascript code. That code comes in as data. So it has the power to override W^X.
- comex 8y ago
  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 8y ago
    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 8y ago
      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.
exikyut 8y ago
The author said in the twitter thread that this a kernel panic.
panic 8y ago
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.

avip 8y ago

It also crashes chrome on iphone.

ben-schaaf 8y ago
The underlying browser for chrome on iOS is still safari. The same is true for every other browser.
- sneak 8y ago
  ...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.
  - aaaaaaaaaab 8y ago
    That’s not how it works...
  - pilif 8y ago
    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.
- sebazzz 8y ago
  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?
iamgopal 8y ago
Is not chrome just wrapper on iPhone ?

howdydoo 8y ago

Safari on iOS reminds me of Windows 95 and Active Desktop. Whenever IE crashed, it took the entire shell (explorer.exe) down with it.

bitexploder 8y ago

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.

qrbLPHiKpiux 8y ago

Same here, I thought it was completely sandb0xed

saagarjha 8y ago
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.