1. 16

Here’s a CDN hosting the exploit code (so yes, it will force restart your device if it’s running iOS)

https://cdn.rawgit.com/pwnsdx/ce64de2760996a6c432f06d612e33aea/raw/23f2faa0aadb4babbfd228c8bb32a26a8c51c741/safari-ripper.html

Reddit thread on this topic: https://old.reddit.com/r/netsec/comments/9g21yq/how_to_force_restart_any_ios_device_with_just_css/

  1.  

  2. 7

    I think the most interesting thing here is the exploit causes Safari to crash the whole OS but Chrome iOS (still webkit on ios) only crashes the app. This must mean safari has much deeper access than regular apps. Maybe there are some exploits to be found in safari or optimisations that other apps can’t use.

    1. 4

      That is probably the biggest takeaway in my opinion. Seeing a constant crash on a mobile browser isn’t too common (some of those WebGL demos can really kill some without any problem) but that it translates into a full OS reboot means that there is more to it, as you said. And I wouldn’t be too surprised that the current relationship between default mobile browsers and certain OS’s turns out to be not too dissimilar from the IE + Windows one was.

      1. 4

        WKWebView probably explains this. The old browser widget (UIWebView) couldn’t use the jit because they couldn’t secure it, so Apple developed a new WKWebView that could execute jit’d code (css gets jit’d too) in a separate, heavily isolated process. Chrome for iOS uses WKWebView, whereas Safari presumably uses low-level WebKit.framework + JavaScriptCore primitives directly.

      2. 1

        macOS Safari didn’t like that link either

        Safari:

        Version 11.1.2 (13605.3.8)

        macOS High Sierra:

        10.13.6 (17G65)