Web Browser Security on iOS ⇥ newsletters.feedbinusercontent.com

Lorenzo Franceschi-Bicchierai, reporting for Vice last month:

Since the beginning of 2021, Apple has patched seven bugs that “may have been actively exploited,” according to Motherboards’s count of vulnerabilities mentioned in Apple disclosures. That means the company is relatively confident that some hackers somewhere were taking advantage of those bugs to hack iPhones — something the industry usually refers to as zero-days caught “in the wild.” To be clear, if a bug is being used “in the wild,” that means that a hacker is using it to hack people. In this case, that means Apple fixed these bugs only after iPhone users were being hacked by some unknown-to-us entity.

The good news is that Apple, with the help of other companies and researchers, is not only patching these dozen security vulnerabilities but is also able to see that they are being used in the wild. The bad news is, well, that they were being used in the wild and that there have been seven different vulnerabilities of this type disclosed in the last four months, which is a lot of security vulnerabilities. Out of the seven in the wild vulnerabilities fixed by Apple this year, five of them were in Webkit, the browser engine developed by the company and used in Safari.

Justin Schuh on Twitter:

An attacker with enough resources will inevitably win, and any major software will eventually get hit by a 0day. That stated, Webkit/Safari represents a uniquely soft spot in iOS security, and Apple won’t allow their customers to choose a more secure browser instead.

SecurityWeek’s Ryan Naraine in his Monday Security Conversations newsletter:

Late yesterday afternoon, Apple released an emergency patch to cover a pair of WebKit bugs being exploited in mysterious zero-day attacks on older iPhones. For those keeping count, we’re up to 46 in-the-wild zero-day discoveries so far in 2021. A whopping three-quarters of all the documented 0days in 2021 have hit three prominent vendors: Microsoft (30%), Apple (25%) and Google (20%).

[…]

You see, Apple App Store rules forbid third-party runtimes, which means that Google or Brave or DuckDuckGo or any non-Apple browser cannot ship their own rendering or JavaScript engines on iOS. When you install Chrome on iOS, you’re really running Apple’s Safari (WebKit) with a Chrome UI and interface.

Every time I see a batch of dangerous WebKit/Safari security flaws, I think of these interconnected risks and the false sense of security they bring to modern computing.

As ex-Googler Chris Evans puts it, your Chrome on iOS browser is “typically less secure, slower, less standards compliant.”

While web browsers are a vulnerability on pretty much all platforms, and Apple’s rendering engine restrictions on iOS create a unique single point of failure in WebKit, I do not fully understand this line of reasoning. Naraine does not cite a specific source for his figures, but it is safe to say that a huge number of those Google zero-days have been in Chrome. In fact, at least six Chrome zero-days have been found actively exploited in the wild so far this year, similar to the number of WebKit zero-days. All of those vulnerabilities were found in cross-platform components. I can see good arguments for allowing browser vendors to use their own rendering engines on iOS, but these figures suggest that it will not magically improve security. I do not love the idea of such a singular point of failure but, if anything, a more liberal rendering engine policy means that users would have to contend with vulnerabilities in WebKit and Chrome.