Open Radar

 
[Want to discuss? Get in touch with me @jamesreggio.]

One of the primary value propositions of SFSafariViewController is its sandbox. The sandbox should work in both directions. The obvious direction is that the host app should have no access to the browser process. The less obvious direction is that the browser should have no ability to impact the host app beyond what is defined in the SFSafariViewControllerDelegate. This latter aspect is broken.

More specifically, when the SFSafariViewController remote process crashes, it crashes the host app with absolutely no notification. It is not possible to observe these crashes in a debugger, nor are any crash logs uploaded to Apple for later inspection by the host app developer. (At least, not to my understanding.)

If there is one constant with web browsers, it's that they have bugs which people will consistently find and exploit. If a WebView is not properly isolated from the host app, the host app takes on all of the risk of bugs and crashes of the WebView, despite having no control over the code within the WebView. This is an unfortunate state of affairs, and could lead to DoS attacks on end-users, wherein attackers entice users to click poisonous links to induce a crash.

(It's worth noting that when the remote WKWebView process crashes, it does not crash the host app. This is a problem specifically with SFSafariViewController.)

Steps to Reproduce:
1. Load the app referenced below *on a physical device*.
2. Tap the 'Bugs' tab bar item.
3. Tap the 'Large Resources OOM Crash' button.
4. Wait for several minutes for the many large image resources to exhaust the remote process of memory.

Expected Results:
A number of better things could happen here:
1. The host app crashes, but in a manner that is interceptable.
2. The SFSafariViewController goes blank.
3. The SFSafariViewController dismisses itself and sends the safariViewControllerDidFinish: message.

Actual Results:
Instead, the host app eventually terminates. If a debugger is attached, it simply becomes detached (with no exception or breakpoints triggered) and asks to be manually re-attached.

Version:
iOS 9.1 (13B137)

Notes:
The sample project is available on GitHub here:
https://github.com/jamesreggio/SFSafariViewControllerPlayground

It is important to reproduce this issue on an actual device since the simulators are not subject to the same memory restrictions.

The crash is being forced via native memory exhaustion using excessively large images because this is a timelessly reliable way to crash a browser. I imagine this bug also reproduces using other unpatched known browser exploits or a simple, forced SEGFAULT within the remote process.

Configuration:
iPhone 6 on iOS 9.1 (13B137)