Chromium Full Disk Read / Write Vulnerability

Skipping over a naïve prevention mechanism

Historically, filesystem access via the browser has been fraught with bugs in both Flash and Silverlight. The industry agreed, twice, that browsers accessing the filesystem was a bad idea and vowed never again to dream up such an API. In 2020 a draft standard for a JS file system access API was proposed and later added to Chromium :)

Weaponising this on a red team would be a great way to remotely snarf credentials and execute code, bypassing many of the security measures used to curb typical phishing methods. After looking at Chromium's implementation, two few things became clear:

  1. A block-list approach is used
  2. Select sensitive system paths are blocked: C:\Windows, ~/.ssh etc.
Chrome blocking access to sensitive folders

The security consultant part of my brain was quick to scream that block-list based approaches are rife with bypasses. My goal became clear: achieve full disk read / write via a malicious site loaded in Chromium (the underlying engine for Chrome / Edge).

The bypass was spectacularly unremarkable. Rather than prompt the user to give the site read / write access to C:\ - only to get blocked, prompt for \\localhost\C$ - an internal alias on Windows for the C:\ drive. This bypassed the block-list and allowed me to do naughty things like:

  1. Exfiltrate:
    1. Credentials
    2. Browsing history
    3. Personal documents
    4. System configs / installed software
  2. Write:
    1. Malware
    2. New software configurations

Timeline:
2022-5-17 Heard about the filesystem API
2022-5-17 Found Chromium's block-list and identified bypass
2022-5-18 Proof of concept developed
2022-5-18 Reported to Google
2022-10-4 Patch pushed (by blocking UNC paths rather than implementing an allow-list 👀)
2023-12-28 $1000USD payout 2023-1-10 First Chrome release with patch
2023-2-11 Made public