1549833 - (CVE-2019-11700) Lack of mitigation on external protocol execution (res: protocol)

Status: VERIFIED FIXED

(Core :: Networking, defect, P2)

Description

[James Lee]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36

Steps to reproduce:

We can run res:// scheme from Firefox, which allows us to run JavaScript at renderer process privilege (Low IL) in Internet Explorer.

POC:

<script>window.open("res://apds.dll/redirect.html?target=javascript:alert(1)", "_self");</script>

Test on: https://pwning.click/ffres.php

Actual results:

Firefox open res:// URL which runs JavaScript at renderer process privilege (Low IL).

Expected results:

Firefox does not allow res:// URL

Comment 1

[:Gijs (he/him)]

[Tracking Requested - why for this release]:
I'm 90% sure this is just a pref flip, we should fix this.

Comment 2

[:Gijs (he/him)]

The summary is generic, but the steps here only highlight the res: protocol on Windows. Are there other protocols you're aware of that need restricting? What do other browsers (esp. other than IE, of course) do?

Comment 3

[James Lee]

1. That example runs JavaScript from IE normal protected mode sandbox, which has more attack surface & vulnerable.

2. We are able to run Medium IL JavaScript using IE bug.

Test on: https://pwning.click/ffres2.php

For answer to the question, Edge and IE does not allow redirection to res:// scheme. Chrome allows to open res:// but prompts opener which has default on set on "cancel" but not open button. Also, Chrome's URI opener disappears when page is redirected to Cross-Origin site, while Firefox's Launch Application opens normally with default set on "open link" button after Cross-Origin redirection.

Comment 4

[:Gijs (he/him)]

Attachment: Bug 1549833, r?valentin

Comment 5

[:Gijs (he/him)]

Comment on attachment 9063361 [details]
Bug 1549833, r?valentin

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Fairly easily
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
• Which older supported branches are affected by this flaw?: Everything
• If not all supported branches, which bug introduced the flaw?: None
• Do you have backports for the affected branches?: Yes
• If not, how different, hard to create, and risky will they be?: Trivial - it's just setting a single pref. That pref has been supported since ~forever. We could even hotfix for 66 if we think this is severe enough, but I think it (a) probably isn't and (b) we're releasing 67 soon so I don't think there's a point.
• How likely is this patch to cause regressions; how much testing does it need?: It won't. Knowing the craziness of the internet, there might be complaints that we broke a "convenient" way of launching IE from Firefox. From a quick look, this hole is not abused by extant add-ons on AMO, which use native client APIs to start IE.

Comment 6

[:Gijs (he/him)]

(To be clear, there is nothing in the checkin comment or as comments in the patch, but purely the patch contents should be enough for people to work out where the issue is.)

Comment 7

[Daniel Veditz [:dveditz]]

Comment on attachment 9063361 [details]
Bug 1549833, r?valentin

Sec-approval=dveditz

Comment 8

[:Gijs (he/him)]

Comment on attachment 9063361 [details]
Bug 1549833, r?valentin

Beta/Release Uplift Approval Request

• User impact if declined: People can link to the res: protocol which can be dangerous to users
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See comment #0
• List of other uplifts needed: n/a
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is just a (hidden) pref flip building on existing infrastructure to disallow linking to certain protocols
• String changes made/needed: n/a

Comment 9

[James Lee]

Is it sec-low when I can run Medium IL JavaScript and any files using this bug?

http://pwning.click/ffres3.php

https://www.youtube.com/watch?v=p8DMXE_DL9M&feature=youtu.be

Comment 10

[:Gijs (he/him)]

This landed last night.

https://hg.mozilla.org/mozilla-central/rev/465fa362c7020a91a653ba36f068487558114b89

Comment 11

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9063361 [details]
Bug 1549833, r?valentin

Approved for our beta branch, thanks.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/b620b8ee82853fa4ec7d25d27d7f347f42e87021

Comment 13

[:Gijs (he/him)]

(In reply to James Lee from comment #9)

Is it sec-low when I can run Medium IL JavaScript and any files using this bug?

http://pwning.click/ffres3.php

https://www.youtube.com/watch?v=p8DMXE_DL9M&feature=youtu.be

Needinfo for Dan to have a chance to consider this, but:

• there's a prompt (however imperfect the prompt is, you filed another bug about that...), and the requirements for user interaction probably constrain the overall severity
• I don't know anything about high/medium/low IL stuff in IE, but if you can escalate what happens in IE (which is what I assume based on comment #0 which talks about low IL, vs comment #9 talking about medium IL) that seems like more of an IE bug than anything else.

Comment 14

[:Gijs (he/him)]

Do we want this on ESR, considering it's a pref flip so it's easy to fix?

Comment 15

[Ryan VanderMeulen [:RyanVM]]

I'm worried about enterprises which might use this "feature" in their environments. Given the low severity, I'd probably lean towards not uplifting to ESR unless there's a compelling reason to do so.

Comment 16

[Daniel Veditz [:dveditz]]

Needinfo for Dan to have a chance to consider this,

In broad strokes this is roughly equivalent to opening a file:/// url in Firefox, which we try hard to prevent. In the file:/// case we simply don't allow it (unless you copy paste into a fresh tab); with res: we have just a prompt between opening it or not, like any other registered URL Handler. Shortcomings in the delay and the "hold down enter" attack on that prompt are already on file, but fair to consider given that MS has apparently blocked res: since IE6 SP1 (from the Internet Zone at least).

The attacker still can't "read" the files, only cause files at known locations to be loaded. There might be an IE exploit, and that's a worry, but it's as likely from a remote web page as a local file. Maybe if you knew/guessed the download folder, and had previously convinced a user to download an .html file, then you could get it to run locally with same-origin access to all the files on disk (you'd still have to convince the user to allow the page's scripts to run). I'm having trouble talking myself into calling this "moderate". Am I missing avenues for taking advantage of this?

The fact that you can escalate the IE sandbox from low to medium is a bug in IE and not relevant to the firefox severity: that part gets you a sec-vector ("someone else's vulnerability") rating.

Comment 17

[Vlad Lucaci, Desktop QA (:vlucaci)]

Hello,

Managed to reproduce this issue with the Nightly build from 2019-05-07(20190507214514) on Windows 10x64 and with IE 11.706.

Confirming this issue as verified fixed on Nightly 68.0a1(2019-05-10) and the latest Beta 67.0b19.

Comment 18

[James Lee]

Would it be considered as sec-low even I can run Medium IL JavaScript and any files with this bug?(In reply to :Gijs (he/him) from comment #13)

• there's a prompt (however imperfect the prompt is, you filed another bug about that...), and the requirements for user interaction probably constrain the overall severity
• I don't know anything about high/medium/low IL stuff in IE, but if you can escalate what happens in IE (which is what I assume based on comment #0 which talks about low IL, vs comment #9 talking about medium IL) that seems like more of an IE bug than anything else.

1. There's a prompt which is default to "Open link", which allow attackers to trick users by just clicking enter. Also, the Launch Application is present even the page is redirected to other sites which could be a potential problem.

2. You gain mandatory Integrity level of Medium when you achieved full Remote Code Execution "with" Sandbox Escape. Which means, attackers are able to run JavaScript and some commands in normal user's privilege - out side of the Sandbox.

More importantly, this is not an IE bug but a bug when "res://" URL is triggered from other applications such like browsers. So this is a bug in all Windows based applications (windows bug). If you try to open the test link in IE, IE blocks res:// URL correctly at AppContainer. So if we run res://ieframe.dll/navcancl.htm#command on other browsers which are not Microsoft Browsers, IE will pop at Medium IL so we are able to run command at Medium IL.

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

Needinfo for Dan to have a chance to consider this,

In broad strokes this is roughly equivalent to opening a file:/// url in Firefox, which we try hard to prevent. In the file:/// case we simply don't allow it (unless you copy paste into a fresh tab); with res: we have just a prompt between opening it or not, like any other registered URL Handler. Shortcomings in the delay and the "hold down enter" attack on that prompt are already on file, but fair to consider given that MS has apparently blocked res: since IE6 SP1 (from the Internet Zone at least).

The attacker still can't "read" the files, only cause files at known locations to be loaded. There might be an IE exploit, and that's a worry, but it's as likely from a remote web page as a local file. Maybe if you knew/guessed the download folder, and had previously convinced a user to download an .html file, then you could get it to run locally with same-origin access to all the files on disk (you'd still have to convince the user to allow the page's scripts to run). I'm having trouble talking myself into calling this "moderate". Am I missing avenues for taking advantage of this?

The fact that you can escalate the IE sandbox from low to medium is a bug in IE and not relevant to the firefox severity: that part gets you a sec-vector ("someone else's vulnerability") rating.

1. I talked about this briefly in previous reply, we are not only able to run file:// url but also other commands and JavaScript. Running arbitrary Medium IL JavaScript is clearly Privilege Escalation, I believe this deserves at least a moderate severity. Yes, "Hold down enter" attack is already on file. The reason I separately reported is because lot's of users will likely be more convinced to run Launch Application without knowing when we use that bug with this.

2. Well, like I stated before at the least attackers are able to run "Medium IL JavaScript" which I believe it's more severe compared to just reading files. Also, "only cause files at known locations to be loaded." is not true. We are able to load any files from unknown locations too. I do have lot's of IE Vulnerabilities, one of them allows to read files from Medium IL so we are able to combinate Medium IL JavaScript attack to read files but like I said before, running Medium IL JavaScript is already severe enough.

And yes, download html files and running html is also a scenario but I think it's not that useful at the point when you can just run Medium IL JS straightforwardly.

Comment 19

[James Lee]

See also: https://chromium.googlesource.com/chromium/src.git/+/f70c852a6c30fdc989b8f371e2a21128690776ac

Comment 20

[James Lee]

It's assigned as High severity at the time.

Comment 21

[James Lee]

Following example reads chrome.exe from users "without" using IE bug.

Test on: http://pwning.click/ffres4.php

Comment 22

[James Lee]

Is there any consideration upon information I provided?

Comment 23

[Daniel Veditz [:dveditz]]

More importantly, this is not an IE bug but a bug when "res://" URL is triggered from other applications such like browsers. So this is a bug in all Windows based applications (windows bug).

Fair enough, I should have said it's a "Microsoft" vulnerability. If res: is too dangerous to allow from IE's internet zone it shouldn't be an advertised "URL Protocol" in the system for all apps to use.

Following example reads chrome.exe from users "without" using IE bug.

You caused the content to open in notepad; the victim is the one reading it. Maybe you can get there if you can open your own content as .html from the local zone, then you could read other files with xhr and post them back to the attack server. Seems reasonably likely that it's possible, but that's not what your example shows.

Comment 24

[James Lee]

We are able to disclose OS username using input tag:

http://pwning.click/osuname.php

We are able to detect the file presence from local zone and AppContainer using onreadystatechange:

<iframe src="res://C%3a%5cProgram Files%5cWindows Media Player%5cwmplayer.exe/24/1" onreadystatechange="count++"></iframe>
<script>
count = 0;
window.onload = function()
{
if (count == 1) alert("File exists!");
else alert("File does not exist");
}
</script>

We are also able to steal the file from user on local zone and Low IL using hyp3rlinx's XXE bug:

http://hyp3rlinx.altervista.org/advisories/MICROSOFT-INTERNET-EXPLORER-v11-XML-EXTERNAL-ENTITY-INJECTION-0DAY.txt

Comment 25

[James Lee]

Btw, we can force user to download file just by visiting website. So above examples show that's possible in any case.

Comment 26

[James Lee]

(The location of Download folder in Windows is C:\Users%USERNAME%\Downloads)

Comment 27

[James Lee]

(In reply to James Lee from comment #26)

(The location of Download folder in Windows is C:\Users%USERNAME%\Downloads)

C:\Users%USERNAME%\Downloads

Typo corrected.

Comment 28

[James Lee]

Why does the advisory on FF 67: https://www.mozilla.org/en-US/security/advisories/mfsa2019-13/#CVE-2019-11700 does not include that this issue could be used for Elevation of Privilege, detecting and reading files from users? I assume the later is not included because it's the bug from IE side but the EoP isn't.

Also, even if the later is the bug from IE side, both file detection and reading files are publicly disclosed.

Which means every attacker could've detect, read files and elevate privilege using this bug and combination of those known bug + OS Username reading bug I shared above to execute automate downloaded html file on C:\Users\%USERNAME%\Downloads\exploit.html with no user interaction.

Comment 29

[James Lee]

Thanks for updating information though.