1658881 - (CVE-2020-15680) [VG-VD-20-115] Leaking External URL protocol handler presence through image tags

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Rotem Kerner]

Attachment: ff.html

Dear Mozilla,

Fortinet's FortiGuard Labs have discovered a security issue in your product Firefox on 8/12/2020. We estimate its risk level is 2, on a scale of 1 (lowest) to 5 (highest), in terms of its impact. Please advise of the appropriate contact person in your company to handle this issue.

Fortinet's research remains ethical at all times, and we therefore strive to Responsible Disclosure. Fortinet vulnerability disclosure policy can be found at https://fortiguard.com/zeroday/responsible-disclosure.

For this particular issue, we will wait until 9/13/2020 for vendor response before we post an advisory on our website (https://fortiguard.com/zeroday) and/or any other publication form (e.g. conference talk, demo, podcast, etc.).

In the case you agree to patch this issue, we'll extend the disclosure deadline to 90 days (it's 11/13/2020 for this issue) automatically.

We might disclose it earlier than that date only if:

1. Public proof of concept code for the vulnerability is released or it's disclosed by other people, increasing the danger of the vulnerability being exploited in the wild;

2. Active attack against the vulnerability is detected;

3. Or you have patched the vulnerability or released solution/workaround - a positive fact we'll be happy to mention.

Fortinet will use reasonable efforts to communicate a schedule of planned mediums, including conferences with the appropriate stakeholders within the affected company.

Our security researchers work on your product or service either because it is popular and/or interesting, so please take this positively. This research is done free of charge for you, although our researchers will appreciate being mentioned in a Hall of Fame or bug bounty if any. Threats to our security researchers are not acceptable and will be dealt with by our Legal team.

We look forward to working closely with you to resolve this issue. If you wish to switch to confidential emails, our PGP key can be found at https://fortiguard.com/secresearch-pgpkey.

Kind regards,

Fortinet's FortiGuard Labs.
 

Vulnerability Description:

This vulnerability has been tested on Firefox 78.0.1 (64-bit) under Windows 10. To leak the protocol handlers in Firefox, we leverage differences in the way Firefox renders images sourced from existing and non-existing protocol handlers.

For example, if we try to load a web page containing the following element -

<img src=”search-ms://abc”>

and observe the elements styling using developer tools, we would see that the default styling for broken images generates element with size of 24x24. Unlike the example above, if we try to create an image element and set source to some non-existent handler like the following -

<img src=”NonExistingHandler://abc”>

this will result with an element with different sizing of 0x0.

This difference can be measured using a simple JS script. Basing on this, a malicious actor may perform a brute-force attack to disclose the different protocol handlers on a targeted system.

please note that the ff.html file contains the PoC for this vulnerability.

Thanks,

Rotem Kerner

Comment 1

[Rotem Kerner]

Attachment: Leaking URL Handlers in Mozilla Firefox - First Notice.docx

the report in a nicer looking doc file :)

Comment 2

[Rotem Kerner]

Some words about impact -

Vulnerabilities Impact

Such information disclosure vulnerability could be exploited in several different ways. Here are some examples:

• Identifying communication channels: By listing the handlers an attacker can get a hint to what platforms he may use for reaching the targeted user. For instance, detecting social applications such as slack, skype, whatsapp or telegram may be used for communicating with the target.
• General reconnaissance: A wide range of applications nowadays uses custom URL handlers and can be detected using this vulnerability. Some examples: music players, IDE, office applications, crypto-mining, browsers, mail applications, antivirus, video conferencing, virtualizations, database clients, version control clients, chat clients, voice conference apps, shared storages
• Pre-exploitation detection: Exploit kits may leverage this information in order to identify if a potentially vulnerable application is present without exposing the vulnerability itself.
• Detecting Security solutions: The Table bellow contains a list of some security solutions whose presence can be exposed by leveraging the vulnerabilities because they have custom protocol handlers installed. Attackers may use this to further customize their attack to be able to circumvent any protection mechanism set by those security solutions.
• User Fingerprinting: reading what protocol handlers exist on a system may also be used in order to improve browser/user fingerprinting algorithms.

Vendor	Protocol Handler
GData	GDataGDATAToastNews://
MalwareBytes	malwarebytes://
Avast	avastpam://
TrendMicro	vizorwebs://, tmtb://, titanium://, vizorweb://
BitDefender	bdlaunch://

Comment 3

[:Gijs (he/him)]

Emilio, I debugged this a little bit, and AFAICT the issue is that for known protocols, creating the channel works but calling AsyncOpen fails with NS_ERROR_CONTENT_BLOCKED. For unknown protocols, creating the channel fails immediately.

What I don't really understand is that it would seem that the DOM image loading content's mBroken is set in both cases, but only one of them ends up showing the "broken image" placeholder. Do you have ideas about this?

(I'll note that this distinction could well mean that there are event firing differences between the two loads, too, in addition to the broken image difference, and so maybe the correct fix would be to make both attempts fail at the same time rather than only fixing the broken image rendering - it's hard for me to tell as I'm not familiar with the code so I'm unsure which behaviour is closer to the one we want.)

Comment 4

[Daniel Veditz [:dveditz]]

we shoudl check what type of error event is sent to onerror and make sure they can't pick up the difference that way, too.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

This looks similar to bug 1626068. See the test-case in the dev-platform thread for example, <iframes> with unknown protocols show an error page, which is considered cross-origin, and thus .contentDocument and so on is not accessible and throws.

We can probably mitigate this for <img>, and maybe for <iframe> as well. Other browsers also expose this information similarly, see that thread.

Main concerns is that some applications may legitimately use this to detect whether their protocol is registered, and offering you some sort of install prompt instead. This is definitely a fingerprinting surface.

The sizing of the image can probably be explained by different outcome in one of these lines: https://searchfox.org/mozilla-central/rev/3434a9df60373a997263107e6f124fb164ddebf2/layout/generic/nsImageFrame.cpp#192-203

Comment 6

[Anne (:annevk)]

FWIW, I don't think we should be exposing what URL schemes the user has functionality for to the web even if there might be legitimate usage and we should try getting rid of it mostly per the design Emilio and I came up with. One adjustment we have to make for compatibility, as illustrated by bug 1650162, is that navigating the frame to such a URL scheme should still cause the new tab or app to be opened.

I agree that we need to be careful about rolling this out, but I don't think it's an acceptable end state to keep leaking this forever.

See also the discussion in https://github.com/mozilla/standards-positions/issues/213.

Comment 7

[Rotem Kerner]

Hi guys, are intending issuing a CVE for this vulnerability ?

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1658881 - When failing to create a channel and an image request, make sure to set the image blocking status appropriately. r=tnikkel

This is the same status as we do for known no-data protocols here:

https://searchfox.org/mozilla-central/rev/ac142717cc067d875e83e4b1316f004f6e063a46/dom/base/nsNoDataProtocolContentPolicy.cpp#59

This ensures we treat these two cases the same.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

I finally took some time to look at this. On the "unregistered protocol" case, we fail to create a channel. We reject the known-protocol image load via CSP instead, which sets a different image blocking status.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

(In reply to Rotem Kerner from comment #7)

Hi guys, are intending issuing a CVE for this vulnerability ?

Re. this question... I dunno, Tom?

Comment 11

[Tom Ritter [:tjr] (OOTO until mid-August)]

(In reply to Rotem Kerner from comment #7)

Hi guys, are intending issuing a CVE for this vulnerability ?

Yes; our workflow will issue a CVE when we have issued a fix; now that there is a patch, it will likely go out Firefox 82.

Comment 12

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Backed out for failures at test_docwrite_meta.html:
https://hg.mozilla.org/integration/autoland/rev/622c63ce4f8090ed37c55c396b0f63063533af48

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&resultStatus=retry%2Ctestfailed%2Cbusted%2Cexception&revision=b5d39e472f05f3f38c10d3fdd61eb7b9a3ee8a50

Previous landing: https://hg.mozilla.org/integration/autoland/rev/b5d39e472f05f3f38c10d3fdd61eb7b9a3ee8a50

Comment 13

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/autoland/rev/8ee4c4a5cb6d96d39eb7c7cbb3a431bdf20938c1
https://hg.mozilla.org/mozilla-central/rev/8ee4c4a5cb6d

Comment 14

[Brindusa Tot, Desktop QA]

I used the attached file "ff.html" on latest Nightly 83.0a1 (09.22.2020) and on Beta 81.b9. ON both builds I observed under Inspector two elements one of 0x0 size and one of 24x24 size. Also on both I have the following error in browser console:
NS_ERROR_NOT_IMPLEMENTED: Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIHandlerInfo.hasDefaultHandler] HandlerService.js:482
fillHandlerInfo jar:file:///C:/Users/brindusa.tot/Desktop/LatestNightly64/omni.ja!/components/HandlerService.js:482

Rotem, am I missing something? What are the differences I should see on a build with the fix vs a build without the fix?

Comment 15

[Emilio Cobos Álvarez (:emilio)]

On fixed builds you should see all handlers reported as "Exists", regardless of whether they exist on your system.

Comment 16

[Brindusa Tot, Desktop QA]

For a build with the fix, latest Nightly 83.0a1 (Build ID 20200922154306), I have 2 handlers reported with "Does not exists":
- Handler https Does not exists
- Handler http Does not exists

For a build without the fix, there are a lot of handlers with does not exists (around 47).

Is this correct?

Comment 17

[Emilio Cobos Álvarez (:emilio)]

Yeah, that sounds good. http/https being reported as not existing are kinda a bug in the test-case (because in that case we actually perform a connection but the test-case tests synchronously).

Comment 18

[Brindusa Tot, Desktop QA]

Thanks Emilio. Marking this Verified.

Comment 19

[Julien Cristau [:jcristau]]

Do we want to uplift this for 78.4?

Comment 20

[Emilio Cobos Álvarez (:emilio)]

It's a sec-moderate, so not sure. Shouldn't be hard to uplift. Tom?

Comment 21

[Tom Ritter [:tjr] (OOTO until mid-August)]

I don't think uplift is needed, and perhaps better to just let it ride the trains.

Comment 22

[Tom Ritter [:tjr] (OOTO until mid-August)]

Attachment: advisory.txt