Chromium site isolation bypass allows wide range of attacks on browsers

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

A bug in the Chromium project allowed attackers to bypass site isolation protection through iFrames and popup windows to carry out a host of malicious activities.

The security weakness 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 every origin’s renderer in a different process to prevent different websites in a browser from accessing each 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 the process lock does not match and block access.

“Both 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,” Alesandro Ortiz, the security researcher who discovered the bug, told The Daily Swig.

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

Catch up 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 a new tab, with a specially crafted URL that keeps the initial navigation entry for the new window. It can then access the data of the top window.

“The initial navigation entry is supposed to inherit the origin of the opener, but the bug causes the navigation entry to inherit the origin of the top-most page,” Ortiz said.

A broad range of attacks

“There are only a couple of ways to trigger the bug, but there is a broad range of ways to exploit it,” Ortiz explained. In essence, anything that has not been protected by process locks can be exploited through the vulnerability.

Ortiz details some of these exploits in his report.

For example, in e-commerce websites, chat applications, and social networks, an attacker would be able to read cookies, IndexedDB data, and CacheStorage data, any of which may contain sensitive data, including authentication info 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 postMessage, WebSockets, BroadcastChannel, and SharedWorkers communication APIs, which may contain sensitive data, including authentication info.

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

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

This is not the first time that a site isolation bypass bug has been discovered. However, most of the recent site isolation bypasses affect a single feature or a small subset of features while the latest vulnerability is more wide ranging in its 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 only one of these values would trigger either process lock checks or other site isolation checks.”

Going down the rabbit hole

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

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

“On March 30th, 2022, a researcher sent me a Twitter DM about potentially unexpected behavior when trying CVE-2020-6506’s PoC in Chrome,” Ortiz said. “The initial details were vague and I often get outreach from researchers confused about expected vs observed behavior regarding this CVE, but I try to chase down every reasonable lead.”

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

“At this point I realized there was likely an interesting security issue here, so I kept investigating,” Ortiz said.

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

“I kept investigating and quickly identified there were further impacts. The full investigation took a while, but I realized this was a wider-impact bug within a couple of hours of submitting the initial report,” he said.

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

Bad coding

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

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

“Different changes over time plus lack of context is usually a recipe for bugs, sometimes with security implications. I can’t speak on behalf of the Chromium team, but I personally 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 MAY ALSO LIKE Chromium browsers vulnerable to dangling markup injection