Bypassing Chromium Site Isolation Enables a Wide Range of Attacks on Browsers


Vulnerability that opened the door to cookie modification and data theft resolved

A bug in the Chromium project allowed attackers to bypass site isolation protection via iFrames and pop-ups to carry out a host of malicious activities.

The security flaw opens the door to a number of exploits, including stealing private information, reading and modifying cookies, and gaining access to microphone and camera feeds.

The vulnerability – which was recently patched – was caused by a code change made to a previous version of the browser.

Site Isolation Bypass

Site isolation is a security feature that puts each origin’s rendering engine in a different process to prevent different websites on one browser from accessing the other’s data. The technology also allows the browser to assign each renderer a specific origin, which it calls “process locks.”

Process locks are checked before allowing sensitive actions requested by the origin. If a renderer pretends to be another origin, the browser will notice that the process lock does not match and block access.

“The two techniques combined prevent memory-compromised renderers or logic bugs such as my bug from being able to read, modify, or perform sensitive actions related to another origin,” said Alesandro Ortiz, the security researcher who discovered the bug. The daily sip.

“There are other controls that are also used to enforce site isolation, but they are less robust than process locks. This bug bypasses these less robust checks.

Keep up to date with the latest browser-related security news

According to Ortiz’s findings, the vulnerability is triggered if an embedded iFrame opens a new window, such as a popup or new tab, with a specially crafted URL that retains the original navigation input for the new window. He can then access the data in the top window.

“The initial navigation input is supposed to inherit the origin of the opener, but the bug causes the navigation input to inherit the topmost page origin,” Ortiz said.

A wide range of attacks

“There are only two ways to trigger the bug, but there are a wide range of ways to exploit it,” Ortiz explained. Essentially, anything that hasn’t been protected by process locks can be exploited through the vulnerability.

Ortiz details some of these feats in his report.

For example, in e-commerce sites, chat applications, and social networks, an attacker could read cookies, IndexedDB and CacheStorage data, each of which may contain sensitive data, including authentication information for account access. In cases where the website has been granted access to the device’s microphone or camera, the attacker will be able to silently record the victim’s conversations or visible activity.

A potential attacker will also be able to receive messages from the website using postMessageWebSockets, BroadcastChanneland Shareworkers Communication APIs, which may contain sensitive data, including authentication information.

iFrame sandboxing can mitigate the attack if “permission-scripts” and “allow popups” are not present. In some cases, the attack requires “allow same origin” to activate.

“Unfortunately, ‘permission-scripts‘ and ‘allow same origin‘ are quite common, and ‘allow popups‘ is also present in many cases,” Ortiz said.

This isn’t the first time a site isolation workaround bug has been discovered. However, most recent site isolation bypasses affect a single feature or a small subset of features, while the latest vulnerability has more widespread effects.

“This bug is unusual in that it spoofs several different values ​​that are used by many important features to enforce site isolation, hence the much wider impact,” Ortiz said. “Typically, spoofing just one of these values ​​would trigger either process lockout checks or other site isolation checks.”

Down the rabbit hole

In 2020, Ortiz discovered CVE-2020-6506, an XSS (Universal Cross-Site Scripting) bug in Android WebView (part of Chrome). The proof of concept (PoC) for this bug involved calling with a javascript: URLs.

The PoC used a JavaScript dialog as a way to demonstrate the impact. This PoC and a tip from another researcher helped Ortiz find the new bug.

“On March 30, 2022, a researcher DMed me on Twitter about potentially unexpected behavior when testing the PoC of CVE-2020-6506 in Chrome,” Ortiz said. “Initial details were vague and I often get researchers confused as to expected versus observed behavior regarding this CVE, but I try to pursue all reasonable leads.”

After some exploration, Ortiz realized that the JavaScript dialog was showing an incorrect origin, a telltale sign of a potential security hole.

“At this point, I realized there was probably an interesting security issue here, so I continued to investigate,” Ortiz said.

Ortiz submitted the initial Chromium security report only knowing the impact of the JavaScript dialog, as that in itself was already a vulnerability.

“I continued to investigate and quickly identified that there were other impacts. The full investigation took some time, but I realized it was a bug at more broad impact within hours of submission of the initial report,” he said.

The full bug report is an interesting study of going back and forth between researcher and provider, while finding new exploits along the way.

Bad coding

According to Ortiz’s findings and the Chromium bug tracker thread, a misunderstanding of the logic behind the functions for opening new windows in the browser has introduced the site isolation bypass into one Chromium version 98 commits. This bug was in Chrome Canary for about four months and in the stable release for about two months before it was discovered.

“There are always interesting bugs, even in secure software like major browsers,” Ortiz said. “Even the best programmers accidentally make mistakes. I probably would have made the same mistake under the same circumstances as the committer.

“Different changes over time and a lack of context are usually a source of bugs, sometimes with security implications. I can’t speak for the Chromium team, but personally I don’t think there was a single point of failure here,” Ortiz concluded.

Ortiz was awarded $20,000 in bug bounty by the Google Vulnerability Reward Program (VRP) panel, of which he gave $4,000 to a collaborating researcher.

YOU MIGHT ALSO LIKE Chromium browsers are vulnerable to hanging markup injection


Comments are closed.