1740725 - Chromium has different rules for loading blob: content created from a file:// document.

Status: RESOLVED INCOMPLETE

(Core :: DOM: Core & HTML, defect)

Description

[Kirtikumar Anandrao Ramchandani]

Attachment: uxss.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36/8mqDoRuL-01

Steps to reproduce:

1. Open the attached file in the Firefox
2. Open Console

Actual results:

It loaded local resource

Expected results:

It shouldn't load local resource

Comment 1

[Kirtikumar Anandrao Ramchandani]

Details: You can exploit that UXSS by the idea is that if javascript:alert(document.domain) shows "http://microsoft.com" then you could change the code to alert(document.cookie) and that would let you steal the cookie for microsoft.com. But this will require tweaking the attack a bit more. I didn't try running that or anything, but the overall idea would be that if your alert(document.domain) call there showed the domain of your choice.

Chrome and other chromium-based browser don't seem to be vulnerable. The issue was previously found in Yandex and they have patched: CVE-2021-25257

Comment 2

[Daniel Veditz [:dveditz]]

I'm sorry, I don't see anything like that on the console, and I don't see a javascript popup. I also can't find any information about CVE-2021-25257 or find a Yandex advisory mentioning it.

Comment 3

[Kirtikumar Anandrao Ramchandani]

Hello,

I also can't find any information about CVE-2021-25257 or find a Yandex advisory mentioning it.

CVE isn't published yet, can share the email screenshot.

I'm sorry, I don't see anything like that on the console, and I don't see a javascript popup.

It wasn't experienced on my side too. But whenever we open the exploit locally, we will have below observations:

Chrome: Not allowed to load local resource: blob:null/52ee30e0-b660-4d5d-bf35-55d6ee562a4f#btn under the console
Brave: Not allowed to load local resource: blob:null/eaeecbbf-cfc8-4295-b069-d02595c4ac24#btn under the console
Firefox:

The stylesheet data:,aaaaazxczxczzxzcz was loaded as CSS even though its MIME type, “text/plain”, is not “text/css”. 86219e5f-6d67-4dc6-9d38-4b7e9a9a7315
The character encoding of a framed document was not declared. The document may appear different if viewed without the document framing it. 86219e5f-6d67-4dc6-9d38-4b7e9a9a7315

The line of MIME shows UXSS due to MIME sniffing. That's what we're pointing to. If you want, I can request for information from Yandex but the team hasn't been responding since too long after the Address bar spoofing cases were sent to them.

Comment 4

[Kirtikumar Anandrao Ramchandani]

Details on the case were shared on [e-mail]. Please check.

Comment 5

[Daniel Veditz [:dveditz]]

OK. so "Universal Cross-Site Scripting" is a red-herring and that's what I've been trying to find here. There is no UXSS seen when I run this testcase myself nor in the movie you sent me.

I assume "open the exploit locally" means "save the exploit to a file, and open it using a file:// URL". It would be good to be a precise as possible in your STR so we don't have to guess.

The reason we gave the warning and still loaded the CSS file is because 1) we're in quirks mode, and 2) it's same-origin.
https://searchfox.org/mozilla-central/rev/6deb8b6af57a8b5b6b1bcb143ea498e566475d8d/layout/style/Loader.cpp#797-803

Given "blob:null/..." in the Chrome error messages they are treating this as an opaque origin, which is never same-origin, not even with itself.

The "local resource" in this case means the content created by the testcase itself. It's not allowing the testcase to read content that it doesn't already know. That said, there's no standard for file:/// access and chromium, webkit, and gecko differ a bit on what's allowed and what's not. This is being argued out in WHATWG specs.

The two main differences I see between Gecko and Blink are

1. in Blink the testcase and the frame are cross-origin because they're null origins. In Gecko the frame contents come from a Blob created by the testcase, and a Blob is same-origin with its creator.
2. In Blink the data: stylesheet is a null origin that's cross-origin from the frame's null origin. In Gecko the data: URL was created by the framed content so it's same-origin with that content (for some uses such as resource loading. Not document origins, though).

Granting the behavior is different, where is the vulnerability?

Comment 6

[Kirtikumar Anandrao Ramchandani]

I will add more information after digging up more into this

Comment 7

[Daniel Veditz [:dveditz]]

adding the reporter's needinfo back as a signal we're in a "waiting" state on this bug.

Currently we're thinking this is just a difference between browsers in an under-specified area, and not exploitable.