1578317 - Leaking status code of a cross-origin resource by using an audio/video tag and MediaError's messages

Status: RESOLVED DUPLICATE of bug 1450853

(Core :: Audio/Video, defect, P3)

Description

[Luan Herrera]

Description

By inserting a cross-origin resource into an audio/video tag it is possible to leak its status code by getting the MediaError's message.

This vulnerability is particularly useful for XS-Search attacks, whereby knowing the status code of a cross-origin resource an attacker can infer the state of certain endpoints and then leak information (more on https://github.com/xsleaks/xsleaks/wiki/Real-World-Examples).

Reproduced on Windows 10 using version 68.0.2 (64-bit).

Steps to reproduce

1. Access https://lbherrera.github.io/lab/firefox-7a135d30/index.html
2. Open the DevTools and check the MediaError messages on the console.

Actual results

The real status code of the cross-origin resources was leaked.

Expected results

The real status code of the cross-origin resources shouldn't have been leaked.

Comment 1

[Daniel Veditz [:dveditz]]

I see a bunch of warnings of the form

Error: This error message will be blank when privacy.resistFingerprinting = true. If it is really necessary, please add it to the whitelist in MediaError::GetMessage:

that seems to indicate we know about this issue, and are preventing it in at least one sensitive case. That means there were probably reasons not to block this generally (required by spec, perhaps?). Tom: do you know what the story is here?

Comment 2

[Tom Ritter [:tjr] (OOTO until April)]

(In reply to Daniel Veditz [:dveditz] from comment #1)

I see a bunch of warnings of the form

Error: This error message will be blank when privacy.resistFingerprinting = true. If it is really necessary, please add it to the whitelist in MediaError::GetMessage:

that seems to indicate we know about this issue, and are preventing it in at least one sensitive case. That means there were probably reasons not to block this generally (required by spec, perhaps?). Tom: do you know what the story is here?

Yes and no. We considered that MediaErrors might return fingerprintable information, so we neutered it for the RFP case. The fact that you're seeing the message means you have Resist Fingerprinting turned on, and you're triggering a firefox-developer-intended message. =)

The issue is - almost certainly - about the situation when RFP is off.

Comment 3

[Luan Herrera]

I did some digging and found https://bugzilla.mozilla.org/show_bug.cgi?id=1354633#c6 which explains why MediaError's message returns empty when you have Resist Fingerprinting turned on :)

As a side note, Chrome returns an empty message for cross-origin resources and returns a message when it is a same-origin resource.

Comment 4

[Daniel Veditz [:dveditz]]

I do not have resistfingerprinting turned on. I got the warning that the message would be blank if it's turned on, and then also got the message (reproducing the bug).

Comment 5

[Nils Ohlmeier [:drno]]

Sounds to me like the Chrome behavior is what we want here to be on the safe side.
Jean-Yves, Paul do you guys have any thoughts on this?

Comment 6

[Jean-Yves Avenard [:jya]]

I don't believe there's anything of value in what we are leaking here. It's a conscious choice; at the time we exposed MediaResult we did a security review on the matter. At worse we get link to the source code path as compiled by the builder machine; it's not unique to the user.

We exposed on why a video didn't play or errored, because the video itself contained error, which here would be the cross-origin video. There's no sensitive information being exposed then that can't be accessed outside this method.

Comment 7

[Tom Ritter [:tjr] (OOTO until April)]

(In reply to Jean-Yves Avenard [:jya] from comment #6)

There's no sensitive information being exposed then that can't be accessed outside this method.

I do not believe this is correct. When trying to load a non-video in an audio/video context we disclose the exact status code (200, 302, 404, 500, 412, 403, etc.) via the MediaError Message Outside of this context, the smallest granularity we expose (that I'm aware of) is onsuccess or onerror callbacks for resource loading.

Comment 8

[Nils Ohlmeier [:drno]]

(In reply to Tom Ritter [:tjr] from comment #7)

I do not believe this is correct. When trying to load a non-video in an audio/video context we disclose the exact status code (200, 302, 404, 500, 412, 403, etc.) via the MediaError Message Outside of this context, the smallest granularity we expose (that I'm aware of) is onsuccess or onerror callbacks for resource loading.

To clarify: does this mean that cross origin audio/video tags could be used to gain knowledge about LAN internal pages?

Comment 9

[Paul Adenot (:padenot)]

I think that's correct, this allows scanning a local network more precisely and therefore allowing easier identification. Can we just align with Chrome here, it does seem like the right thing to do? Here is a simple patch for this.

Comment 10

[Paul Adenot (:padenot)]

Attachment: Bug 1578317 - Truncate MediaError.message on cross origin resources. r?tjr

Comment 11

[Paul Adenot (:padenot)]

This is missing tests of course. We can write them if we decide to do this.

Comment 12

[Tom Ritter [:tjr] (OOTO until April)]

Matching Chrome's behavior seems reasonable to me, but I don't think I'm the best person to review this.... I accepted because the code looked good to me but I think you should run this conceptually by someone else...

Comment 13

[Daniel Veditz [:dveditz]]

[csectype-sop because it's cross-origin information being leaked. "disclosure" is usually about leaking user/local information]

Comment 14

[Paul Adenot (:padenot)]

Anne, jya, I think this makes sense for the reasons mentioned earlier, would you mind double checking?

Comment 15

[Anne (:annevk)]

Yeah this looks good. As a reminder, for opaque responses (cross-origin without CORS) we don't want to leak data beyond width/height for image/video resources and probably duration for audio/video resources.

(And we also need to start locking down what we'll consider to be audio/image/video resources in that context as per bug 1532642.)

Comment 16

[Jean-Yves Avenard [:jya]]

As I wrote in the phabricator comment:
may as well turn off completely the message attribute then, because the main users of this attribute would be using CDN to distribute their videos and as such use cross-origin ones.

what about only clearing it outside chrome process?
at least we keep some usability with the media devtools extension.

So it can't be exploited by scripts at least.

Comment 17

[Anne (:annevk)]

Most CDNs support CORS these days and per the patch it seems that if CORS is used nothing is muted here. But yeah, exposing it to devtools seems very reasonable.

Comment 18

[Tom Ritter [:tjr] (OOTO until April)]

(In reply to Jean-Yves Avenard [:jya] from comment #16)

As I wrote in the phabricator comment:
may as well turn off completely the message attribute then, because the main users of this attribute would be using CDN to distribute their videos and as such use cross-origin ones.

what about only clearing it outside chrome process?
at least we keep some usability with the media devtools extension.

So it can't be exploited by scripts at least.

If we do that I would suggest adding an informational message that appears in devtools afterwards indicating this message is not accessible to web scripts and only appears as a debugging aid in devtools. Otherwise people are going to be REALLY confused.

Comment 19

[Paul Adenot (:padenot)]

When adding tests for this, I'm facing the issue that HTMLMediaElement are not considered same-origin unless there is a decoder, so if there is an error on load, we can't do this properly.

The idea seem to be that the decoder owns the channel, that knows if the resource is same-origin or cross-origin.

Comment 20

[Tom Ritter [:tjr] (OOTO until April)]

I found https://bugs.chromium.org/p/chromium/issues/detail?id=828265 which is Chrome's bug.

I also found https://bugs.chromium.org/p/chromium/issues/detail?id=826187 which is a related cross-origin leak (not as direct) which seems related...

Comment 21

[Anne (:annevk)]

FYI: it seems there's also bug 1450853 (public) with a patch now. Not sure what the best course of action is, so I'll needinfo the people involved here.

Comment 22

[Christoph Kerschbaumer [:ckerschb}]

(In reply to Anne (:annevk) from comment #21)

FYI: it seems there's also bug 1450853 (public) with a patch now. Not sure what the best course of action is, so I'll needinfo the people involved here.

I already chatted with Tom about that. Ni? him for visibility. Not sure what the best action is. Tom?

Comment 23

[Tom Ritter [:tjr] (OOTO until April)]

I'll need to confer with Dan and I think he's OOTO this week. Leaving ni.

Comment 24

[Jean-Yves Avenard [:jya]]

posted in the review; there's been no update to this patch since I reviewed it and ask for changes.

Comment 25

[Tom Ritter [:tjr] (OOTO until April)]

The duplicate bounty situation is resolved.