Rapid Response Patch Release From Apple Tackles Critical Issues in an Effort to Close Timeline Gap for Serious Vulnerabilities

In a surprising move on Monday, May 1st, Apple released patches for iOS, iPadOS, and OSX using a new process they are calling Rapid Security Response (RSR). This new delivery method caught many off guard, as Apple had not disclosed any details prior to the release. The new process is aimed at addressing the most severe vulnerabilities and reducing the time high-risk vulnerabilities are left unpatched. However, the lack of transparency and guidance surrounding the new process left many with questions, especially as some users experienced errors or outright failures during installation. In this blog post, the Cybrary Threat Intelligence Group seeks to address some of the most frequently asked questions and provide ongoing analysis of the RSR patches.

What We Know

Rapid Security Response

• Apple released a new patch delivery process they are calling Rapid Security Response
• The process is documented by Apple here: https://support.apple.com/en-us/HT201224
• At the time of writing Apple has no additional details on its security page.

Statement from Cybrary

On Monday, May 1st Apple released patches for iOS, iPadOS, and OSX in a new process called the Rapid Security Responses. This was the first opportunity for consumers and enterprises to be alerted that Apple has implemented a new way to deliver security content beyond an initial announcement at WWDC (WorldWide Developers Conference), their internal developer conference. Apple has not provided any details through their normal security publication channels to the contents of the patch or the motivating factors to change their process. The rollout was not transparent as some users experienced errors or outright failures to install the patches on some devices initially. The new process and installation issues left many with questions about the new process.

FAQ

What happened? Two things.

1. Apple released patches in a new method that the majority of users have never seen before. In details about the new process, Apple used strong language to convey that this process is only for the most severe of vulnerabilities. While not explicitly stated it is implied the process is designed to reduce the amount of time high-risk vulnerabilities that are being used in the wild by threat actors that have driven emergency patching such as two vulnerabilities found being used against real targets and reported to Apple in early April.
2. The new process called Rapid Security Response was used for the first time with this patch. As expected with new processes there were bugs in the form of Apple users attempting to apply the patch shortly after the release encountered errors that caused the patching to fail. This caused some users anxiety that was compounded by this being a new process that even average security professionals were uncertain of, with a lack of disclosure and guidance normally reported through the security details page.

Why?

The new process gives Apple engineers the freedom to ship fixes for specific vulnerabilities that are high risk and would be irresponsible to allow them to go unpatched longer than necessary.

What was the installation error?

For a brief period after release the RSR fix would fail to install with a particular error. Even after the problem was fixed many news and analysis continued to print headlines highlighting the failure. This caused additional confusion because the RSR patches were not released to everyone at the same time. Apple says it is a staged rollout over 48 hours, meaning the patch becomes available to more users as time passes. This confused users expecting to see an update (or didn’t), with users continuing to experience delays after it was fixed. In some cases, the

What is the current state?

1. At the time of publication, the Apple RSR patch (named 16.4.1 (a)) is available and installable.
2. Details about what prompted Apple to take this action, details of what was fixed or disabled, and guidance are absent from Apple’s normal pipelines.

Did this have anything to do with other cybersecurity events on May 1st?

As is common in cyber security many different events are all happening simultaneously and May 1st was no different. May 1st had events such as breach notifications, newly discovered vulnerabilities, or new research and findings of threat actor behavior. One such report was that mobile carrier T-Mobile announced they were recently the victim of malicious actor activity. The timing of the T-Mobile announcement and the Apple RSR lead to speculation they could be related. At this time, however, we have no reason to believe the Apple RSR was tied to any other reported events on Monday, May 1st.

What can I do?

1. When possible apply the fix.
2. If you are in an IT role, make sure your teams have accurate guidance and are aware of sources like the Cybrary blog to check for new information.

Patch severity

1. Apple offers no guidance at this time.
2. Cybrary started its analysis of the patches around an hour after they became publicly available.
3. Using security research techniques and tools, the patches for; iOS, iPadOS, and OSX were all analyzed with a noted common difference in all three systems being a change in Safari. The changes are localized to Webkit-related functionality in a protocol parser. This analysis is ongoing and the blog will be updated promptly.