An active exploit in the wild for a vulnerability in the Apple Safari web browser has been publicly revealed by the Google Project Zero team.
CVE-2022-22620 is the number assigned to the vulnerability. As of 2016, experts have discovered a way to bypass the fix that was implemented back in 2013. Since the flaw was first discovered and fixed in 2013.
This is a zero-day vulnerability “CVE-2022-22620” that has achieved a CVSS score of 8.8 and has been marked with a “High Severity” tag.
The CVE-2022-22620 is a case of a use-after-free vulnerability in WebKit, which affects the browser’s rendering engines. An attacker could exploit this zero-day flaw by creating maliciously composed web content to gain the ability to execute arbitrary code.
Technical Analysis
Apple shipped a patch for the bug in early February 2022 across all its platforms that included:-
- Safari
- iOS
- iPadOS
- macOS
In terms of the usefulness of the History API in 2013 and 2022, both bugs share several significant similarities. Despite this, their method of exploitation for them differs from one another.Â
Following these changes, the zero-day flaw was revived in a zombie-like manner a few years after it had become dormant. While Maddie Stone from Google Project Zero expressed that these problems are not unusual to Safari.
He further emphasized the need for taking the necessary time to analyze code and patches so that there are fewer instances where duplicate fixes are necessary and the effects of the changes on the security of our systems are better understood.
Here’s what Maddie Stone from Google Project Zero stated:-
“Both the October 2016 and the December 2016 commits were very large. The commit in October changed 40 files with 900 additions and 1225 deletions. The commit in December changed 95 files with 1336 additions and 1325 deletions. It seems untenable for any developers or reviewers to understand the security implications of each change in those commits in detail, especially since they’re related to lifetime semantics.”
The question of what should have been done differently is one that cannot be answered easily. As several best practices were already employed by the security experts responding to the original 2013 bug report.
You can follow us on Linkedin, Twitter, Facebook for daily Cybersecurity updates.
