# Instructions (reproduce)

To perform the most basic PoC, which shows how code is executed under `gemini.google.com` within the special webview component, simply:

1. Place all files (`manifest.json` and rules files) within a single folder
2. Load them as unpacked extension via `chrome://extensions` under `Developer Mode`
3. Open the browser and start Gemini in the browser - the attack should take place without additional interaction

As described further below, here are attached a `manifest.json` and a few rules files. There are 5 attacks to be demonstrated.
In order to reproduce each attack, simply enable it by changing `enabled` from `false` to `true` in the `manifest.json` file for the desired attack to be shown. Please have only one enabled at a time. Then, follow the same steps as described above.

NOTICE: in order to examine attack #6 (aka `rules_local_file_read.json`), in addition to the instructions above, please also place the attached PDF file under `/var/tmp/bnbndddd3.pdf` (test on Mac OS). After the attack completes, open the devtools of the Gemini webview process and run `copy(results)` in the console - this will copy a JSON of the results of the attack onto your clipboard. To easily view the results, visit the attached `index.html` file and throw the JSON in the textarea box (for context, even though is not shown in this demo, leaking this information from the process to a remote server is trivial since CSP headers are being removed as part of the attack). 

## Report description

Extensions can hijack Gemini in the browser webview process to perform PE attacks by abusing DNR permissions, allowing stealing prompts, PII leakage, unrestricted access to camera-microphone, read local files, take screenshots and more

## The problem

> Please describe the technical details of the vulnerability

New Gemini in the browser feature in Chrome allows users to activate a new window that renders a special component of a Gemini instance that combines capabilities of generating remote Gemini AI responses and manipulating the browser based on them.

This new component is very clearly a browser-level entity, baked into the browser, aiming to be a builtin enhancement of it, thus superior to websites and installed extensions.

This is clearly proven by Chrome's implemented enforcement around this new component, where affecting it from outside isn't allowed and explicitly blocked. For example, executing content-scripts or attaching debugger capabilities against the special component fail to take place completely.

What's further clear is that this isn't an origin-level decision, but a process decision, because injecting content-scripts to `gemini.google.com` via extensions is allowed if loaded as an ordinary website, but not when attempted against the new special component.

This expresses how Gemini in the browser is a feature that serves the browser itself and therefore must remain superior to inferior entities such as websites an extensions.

Unfortunately, it seems that DeclarativeNetRequests (DNR) permissions were not taken into account, with which a malicious extension can inject code directly under gemini.google.com within the special webview component of Gemini in the browser, thus allowing to undermine and hijack it completely.

All an attacker has to do is to use DNR to remove protecting headers (e.g. CSP, DiP, CORP, etc) and then redirect one script served by the Gemini app with an attacker controlled script.

To be more specific, here are the challenges required to tackle in order to perform the attack successfully:

1. First, find a script that is not necessary for the Gemini web app so we can replace it with our own. For that I picked `https://www.gstatic.com/feedback/js/help/prod/service/lazy.min.js` and used DNR to redirect it to `https://weizmangal.com/public/try.js` which is a JS I control
2. CSP won't allow it, therefore we craft a DNR rule to drop CSP of `gemini.google.com` all together
3. Within the webview context, the Gemini app counts on SAB which requires a document-isolation-policy. This is a problem because that same policy rejects my script coming from a cross-origin, so I simply replace its value to `isolate-and-credentialless` so that SAB works but pulling cross-origin scripts works too
4. Next, since DNR works with `https:` URLs, I had to pull my malicious code from the web, but I didn't want people to see what I'm up to online and also I needed a faster way to work than deploy scripts online every few seconds. Therefore, I implemented a mechanizm that implements the attack in B64 and sets it to the DNR URL as a query param, pointing at a constant online script that takes the B64 from the query param and executes it (this is essentially the only visible difference between each of the attached `rules.json` files). 

## Impact analysis

> Please briefly explain who can exploit the vulnerability, and what they gain when doing so

Anyone with access to installed extensions with common DNR permissions can perform this attack, whether by tricking users into installing malicious extensions or by infecting already legit extensions into doing this (e.g. AdBlock already has necessary permissions to perform such an attack). For starters, `rules.json` shows how we manage to run a simple `console.log` under `gemini.google.com` within the webview.

The impact that can be achieved is as wide as the range of capabilities the Gemini in the browser process is exposed to, for example:

1. An attacker can intercept requests and responses within the app to steal/fabricate prompt communication with Gemini (`rules_intercept.json`)
2. An attacker can phish the user into interacting with fake layout to be tricked into providing sensitive information (`rules_phish.json`)
3. An attacker can ride on the already established communication channel with the host of the webview (`chrome://glic`) and intercept post messages to either steal sensitive information or force the browser to perform sensitive actions (`rules_leak_pii.json`)
4. An attacker can escalate its privileges and access capabilities it does not hold from the stance of an extension, such as camera and microphone (`rules_pe.json`)
5. An attacker can force Gemini in the browser to visit `file://`, allowing listing directories as well as reading local files from the system
6. An attacker can take a screenshot of any website they choose, including `file://` URLs  

All of those will be demonstrated in the attached PoC.

At first glance it might seem that most of this impact can be trivially achieved once an extension has access to DNR permissions. For example, intercepting Gemini requests and/or drawing fraudulent phishing layout can be done against the web app just as well. However, this is fundamentally different for the following reason:

As opposed to the Gemini web app, to which an extension is naturally superior, the Gemini in the browser webview is served as part of the browser, which sends a message to the user that says "this is a highly trusted component, not like websites". Given that, undermining it is more impactful. A proof of that is how the Gemini web app is allowed to be injected with content-scripts, but when loaded within the webview, isn't.

Not only the component can be attacked when looked at as the ordinary Gemini web app, but within this special context, new attack surface becomes available. I was able to ride on the established communication with the embedder of the webview and intercept exchanged messages between them. For example, I've learned how message `glicBrowserGetUserProfileInfo` leaks the name and gmail account that is logged into the browser on the profile level, which is not trivially accessible to extensions. Furthermore, I was able to make the host perform any operation it is designed to support coming from the app, such as opening new tabs, resizing the webview window and more.

This discovery arrives just in time, right before `glicBrowserCreateTask`, `glicBrowserPerformActions`, `glicBrowserJournalSnapshot` and more are fully utilized, allowing attackers to perform far more damage by learning what Gemini actors do and perhaps instruct them maliciously.

On top of that, since the process is endowed with special capabilities such as access to camera or microphone (after user settings activation), malicious code running within this process can access those without prompting the user for permission, unlike how site permissions usually work. This effectively allows an attacker coming from an extension without such power, to ride the Gemini in browser webview and access such devices without any need for user interaction (except for starting Gemini) - aka, a classic escalation of privileges attack. 

Furthermore, it seems the webview can ask for screenshots and contents of focused tabs. Combined with its ability to open and focus on new tabs redirected anywhere we choose, an attacker can practically perform a zero-interaction attack to list local directories, read local files and take screenshots of any tab (including `file://` URLs)

## Choose the type of vulnerability

Privileges Escalation