Apple Safari Developers Patch 9-Year-Old Vulnerability for the Third Time

This is the third time that Apple Safari is patching the same vulnerability that was originally discovered in 2013, then reappeared in 2016 after a code update, and has now been discovered and fixed again, according to a Google Project Zero report.

You might also be interested in reading about how the Unsuccessful Google experiment “broke” Chrome in companies around the world.

Maddie Stone

The issue in question is tracked as CVE-2022-22620 (CVSS 8.8) and is a use-after-free bug in the WebKit component. The vulnerability could be used to execute arbitrary code, and in early February 2022, Apple released patches for this issue in Safari, iOS, iPadOS, and macOS, warning that the vulnerability may already be under attack.

It’s almost the middle of 2022, and we seem to be seeing a trend for such “zombie vulnerabilities. Attackers do not need new bugs to effectively attack users with 0-day, instead they may exploit vulnerabilities that are closely related to previously discovered bugs.writes Maddie Stone, lead researcher on the Google Project Zero team.

Last year, Stone already wrote that a quarter of all zero-day vulnerabilities noticed by Google Project Zero in 2022 were closely related to old vulnerabilities that were publicly disclosed. As a rule, this happens due to incomplete bug fixes.

However, the situation with Safari is slightly different. In this case, Apple completely fixed the problem in 2013, but the patch was “damaged” in 2016, after restructuring the code.

We do not know how long the attackers exploited this vulnerability, but it is known that the vulnerability was present in the code (again) for five years: from December 2016 to January 2022.Stone writes.

The expert said that the original 2013 issue and a related bug discovered this year are related to the History API and could be exploited using specially crafted web content to remotely execute arbitrary code.

This is the same error, but its triggering is achieved in a different way. This is why the 2013 test case did not crash the version of WebKit that should be vulnerable to CVE-2022-22620.the researcher explained.

According to Stone, code refactoring is one of the main problems that developers face. The fact is that developers and security teams need time to test fixes, especially those that are security related.

In this case, nine years after the vulnerability was triaged, fixed, and the patch tested and released, the whole process had to be repeated again, only this time under the pressure of continued exploitation.Stone summarizes.