Over the past few days, Apple users were advised to urgently update the vast majority of iOS, IPadOS, and MacOS devices due to the discovery of two security flaws (software updates for all affected devices are available for download here). While exploitation details are not publicly available yet, the first security flaw (CVE 2022-32893) affects WebKit, a fast, open-source web browser engine. To provide some more details, WebKit is a web content engine for browsers and other applications that powers Apple’s Safari web browser and many iOS web browsers. The security flaw enables the remote execution of code when the user is lured to a malicious web page while using Apple’s browsers. The ability to use this security flaw for remote exploitation of devices is considered a *critical* bug and users are urged to update their devices. Moreover, Apple is aware that this security flaw might be actively exploited. Thus, users are strongly advised to update their devices as soon as possible.

In the heels of the first security flaw, Apple revealed the existence of a second security flaw: a vulnerability (CVE-2022-32894) that targets the core of the device’s operating system (called aptly, kernel). This flaw can enable any attacker using a malicious application to execute arbitrary code with system-level privileges providing direct access to all installed apps and data. Thus, the second flaw can lead to the complete take-over of the affected Apple device. Again, while not much is known about this vulnerability beyond what Apple has disclosed this is considered a high-risk, *critical* security issue. Again, Apple is aware that this security flaw might be actively exploited.

What most others fail to stress is what happens when the two security flaws are combined (or “chained” as is the security lingo). When exploits for the two security flaws are combined creating an exploit chain, they empower a remote adversary to take full control of the victim device including applications, data, and operating system functions. As we have not seen real-world examples of such exploit chains for the two Apple security flaws that were just discovered, it is not clear if hackers were able to successfully produce chains of these vulnerabilities. However, if such exploit chains are generated, they would immediately increase the severity and impact of the attack. The reason being that devices that are successfully exploited using the exploit chain might require hardware reset to allow for the device to be properly updated. Indeed, an attacker using the two exploits can modify or disable Apple’s software update process in the affected device in an attempt to prevent the user from recovering after being infected. Kryptowire has not confirmed the presence of exploit chains in the wild combining the two newly reported Apple security flaws at this point. To make matters worse, the two newly discovered exploits can be combined with other unreported or unpatched exploits increasing the potential for exploitation in all devices without the latest Apple updates.

Unfortunately, this is not the first time that an exploit for the WebKit engine that allows remote code execution has been discovered (see CVE-2020-9948 and CVE-2020-9951 reported in 2020). In fact, security researchers have been finding exploits in the WebKit engine for almost every iOS version that has ever been released. To counter this continuous security threat, Apple has introduced Lockdown Mode on iOS 16. Lockdown Mode, among other things, disables “certain complex web technologies, like just-in-time (JIT) JavaScript compilation, unless the user excludes a trusted site from Lockdown Mode”. While this is a step in the right direction, currently the users cannot select which features of Lockdown Mode they need or even want to enable. As a result, it is highly probable that most users will not enable it at all since “Lockdown Mode offers an extreme, optional level of security for the very few users who, because of who they are or what they do, may be personally targeted by some of the most sophisticated digital threats”. Perhaps Apple should consider offering some automation in selecting security posture instead of relying on users. Moreover, even when users are given the option of enabling which features to disable it needs to be more flexible and more documented. For example, even offering a separate option to temporarily disable the internal WebKit engine completely would probably be more effective. This way users would also be able to easily identify which apps use their own custom in-app browser for potentially other nefarious purposes like injecting additional tracking code into all websites that the users visit through their apps.

One could ask, are we getting better at discovering (and fixing) critical bugs that lead to exploitation? A quick review of the Apple vulnerability landscape shows that we are still playing catchup. According to the National Vulnerability Database that is hosted at the National Institute of Standards and Technology (NIST), vulnerabilities that affected Apple iPhone products were fairly steady over the last 3 years. In 2019, there were 533 reported vulnerabilities while in 2020, there were 490 and 2021 593. So far in 2022, we had 160 security flaws reported. However, the real question is how many of these exploits are severe enough (or can be “chained”) to cause havoc to a victim Apple device and how can the user be protected when Apple is the only source of security (or any) software updates?