Abdulrahman Alqabandi Reporter
	Description • 7 years ago

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

Steps to reproduce:

Tested on latest Nightly v59.0a1 (2017-11-30) (64-bit)

Using PoC attached:

1. Click on first button from the top, this will copy our malicious executable (in this case its my own hosted batch file that simply opens calc)
2. Click on the second button, you should see a drop down menu appear, here you choose the 'Choose Application..' option.
3. After a file picker appears, simply paste the URL copied in step1 and hit 'open'
4. Finally, click the last button.






Actual results:

Firefox has its own preview feed reader for files with the type "application/vnd.mozilla.maybe.feed". Within it, a user could choose a custom application to subscriber to the feed you're viewing. 

When choosing a custom app, a filepicker appears which we can feed an http url into it and after clicking 'open' the remote file will be downloaded into a local temporary folder. Finally, if the user clicks on the 'subscribe' button, the downloaded file will be executed.

In the PoC, we embed the feed preview in order to clickjack a potential victim into executing attacker executable file.
These files have mark of the web and so an initial 'unknown publisher' dialog warning does appear. Though we can bypass this by having a .jar file downloaded instead. Although its good that windows' mark of the web warnings appear for most executables, its not far fetched to bypass this with either a stolen cert or some bug in windows.


Expected results:

One or more of the following:

1. Disable feed preview on embedded feed files (or at least the part that allows custom apps).
2. Prevent file picker from downloading remote files (though this may be a windows unique problem)
3. Add whitelist of directories allowed to contain custom feed reader apps. (or blacklist temp web download folder)

Admittedly this requires high user interaction but keep in mind this highlights a bigger problem, that is that the feed previewer could be used for download&exec exploits. This can turn a uXSS into a full RCE. (I'm assuming here that if one can execute JS within feed preview pages, they could use it to 'fake' a custom app subscription which is essentially download&exec as described here)

	Paul Theriault [:pauljt] (no longer reading bugmail)
	Comment 1 • 7 years ago

Hmm interesting. So when you enter a http: url into a file input field in the windows file picker, it downloads the file to a temp directory, and then returns the temp file the chooser. That I didn't know.

There rest here is pretty much as expected; the feed application chooser floats above content to try to protect against this sort of attack. This is a somewhat convincing attack

From Firefox's perspective, you are choosing an application on disk, that happens to be in the \appData\ directory. You can observe this by looking at about:config, and search for the browser.feeds.handlers.application preference. After I followed your instructions, I ended up with the "application" as:

C:\Users\<redacted>\AppData\Local\Microsoft\Windows\INetCache\IE\<redacted>\a[1].bat

So can we do anything about this? I'm not sure. We could make about:feeds not allowed to be framed or embedded. But there are probably reasons it can be embeded, so you suggest we could remove the control perhaps. I'm included just to prevent framing. as that seems like an odd use case, and not worth the risk here. The windows thing I dont think we can do much. We _could_ blacklist the INetCache dir, but that seems a bit of a weak control.

As for the question of XSS into RCE, you are not able to access the feedreader page with webpage scripts (the feed reader is located at about:feeds which is cross-origin to the embedding webpage). Or are least you _shouldn't_ be able to you. If you manage to achieve that, this would be a separate bug in its own right.


CC'ing a few people who might have some thoughts here. I don't think this is probably only sec-moderate at worst, maybe even this is only sec-low. Bottom line is that if you can convince a user to paste a string into a box pretty powerful things on windows :/ 


PS FWIW Windows Smart Screen actually prevented execution of the bat file, but I wouldn't trust that.

	Abdulrahman Alqabandi Reporter
	Comment 2 • 7 years ago

Although we can do more harmful things (with less user interaction) on windows if a user is willing to copy paste things for us, I think its important to distinguish flaws with windows OS and firefox. 90% of this bug happens within firefox and I imagine firefox users trust web pages not to execute arbitrary code no matter what interaction happens _within web document_. 

I can see this being sec-low except for the bypasses I mentioned. I think the fact that the end result is RCE the high user interaction could be forgiven :)

PoC video of another method that attempts to trick potential victim into clicking 'run' on the windows 'mark of the web' warning. Also please keep in mind we can automatically execute JAR files and completely circumvent the mark of the web warning prompt which adds somewhat to the severity.

	Abdulrahman Alqabandi Reporter
	Comment 3 • 7 years ago

This was optimized for my screen resolution so it may not work as smoothly as it does on my PoC video.

	:Gijs (he/him) Assignee
	Comment 4 • 7 years ago

(In reply to Paul Theriault [:pauljt] from comment #1)
> So can we do anything about this? I'm not sure. We could make about:feeds
> not allowed to be framed or embedded. But there are probably reasons it can
> be embeded, so you suggest we could remove the control perhaps. I'm included
> just to prevent framing. as that seems like an odd use case, and not worth
> the risk here. The windows thing I dont think we can do much. We _could_
> blacklist the INetCache dir, but that seems a bit of a weak control.

Yeah, we should prevent framing. We already try this a little bit, but we should clearly try harder. This has come up before.

We're also considering just removing the feed reader entirely, but that depends on some telemetry etc. (cf. bug 1350349)

	Jonathan Kingston [:jkt] he/him
	Comment 5 • 6 years ago

> Disable feed preview on embedded feed files (or at least the part that allows custom apps)

I assume this won't be a compat issue here? This seems like a good idea to me.

> This is a somewhat convincing attack

Yeah I thought we didn't permit embedding here.

> Finally, if the user clicks on the 'subscribe' button, the downloaded file will be executed.

Yeah given that you can allow Firefox to execute any application through feed reader this kind of attack makes it super worrying that worse would be possible.

Even if this is a sec-low, this concerns me enough that it should stay moderate.

	Kris Maglione [:kmag]
	Comment 6 • 6 years ago

From what I can tell, this doesn't seem related to WebExtensions at all. Moving to RSS component.

	:Gijs (he/him) Assignee
	Comment 7 • 6 years ago

(In reply to Abdulrahman Alqabandi from comment #0)
> 1. Disable feed preview on embedded feed files (or at least the part that
> allows custom apps).

Paul filed bug 1445106 as a public bug to at least prevent framing about:feeds to mitigate this.


> 2. Prevent file picker from downloading remote files (though this may be a
> windows unique problem)

I tried to find information about this but I was unable to find anything to suggest this is possible in the relevant windows docs. Did I just miss it? Jim, do you know?

(for context: apparently in windows' "open file" dialogs, you can paste a http/https (maybe ftp?) URL in the file name box, and hit OK, and Windows will conveniently download said file into somewhere in %TEMP% and then pass the calling app a ref to the downloaded file. I think we should disable this functionality in Firefox if we can, but I'm not sure it's possible)

> 3. Add whitelist of directories allowed to contain custom feed reader apps.
> (or blacklist temp web download folder)

Longer-ish-term (possibly Firefox 61/62, likely not 60 though we might add an about:config pref for it), we are looking at removing feed preview support entirely. So not sure (3) is worth it.

	Jim Mathies [:jimm]
	Comment 8 • 6 years ago

(In reply to :Gijs from comment #7)
> (In reply to Abdulrahman Alqabandi from comment #0)
> > 1. Disable feed preview on embedded feed files (or at least the part that
> > allows custom apps).
> 
> Paul filed bug 1445106 as a public bug to at least prevent framing
> about:feeds to mitigate this.
> 
> 
> > 2. Prevent file picker from downloading remote files (though this may be a
> > windows unique problem)
> 
> I tried to find information about this but I was unable to find anything to
> suggest this is possible in the relevant windows docs. Did I just miss it?
> Jim, do you know?
> 
> (for context: apparently in windows' "open file" dialogs, you can paste a
> http/https (maybe ftp?) URL in the file name box, and hit OK, and Windows
> will conveniently download said file into somewhere in %TEMP% and then pass
> the calling app a ref to the downloaded file. I think we should disable this
> functionality in Firefox if we can, but I'm not sure it's possible)

Can we just not pre-populate the file picker? I'm not aware of a way to turn this off.

	:Gijs (he/him) Assignee
	Comment 9 • 6 years ago

(In reply to Jim Mathies [:jimm] from comment #8)
> Can we just not pre-populate the file picker? I'm not aware of a way to turn
> this off.

We don't, the PoC depends on the user pasting the URL after copying it to the clipboard using JS APIs.

	Abdulrahman Alqabandi Reporter
	Comment 10 • 6 years ago

The clickjacking aspect of the original PoC has been fixed by bug 1445106, this renders the bug much less severe as the only way to exploit it now is if you somehow convince a user to visibly add an application and copy paste a url in the feed reader preview page.

	Abdulrahman Alqabandi Reporter
	Comment 11 • 6 years ago

Looks like this is fixed, seems like the feed reader has been removed (?) rendering this bug fixed. Tested on 64.0b3 and 65.0a1. 

May I get a bounty tag added for consideration? (not sure if I can just do it myself)

	Ciprian Georgiu, Desktop QA
	Comment 14 • 6 years ago

I have reproduced this bug using the test case from comment 0, on an affected Nightly build (2017-11-30).

I can confirm that the button "Click here second", doesn't trigger anymore the app, in order to run the exploit. Tested on latest Nightly 65.0a1 and Beta 64.0b11 under Windows 10 x64.

	Daniel Veditz [:dveditz]
	Comment 15 • 5 years ago

Adding the dependency on bug 1445106 (don't frame me, bro) which largely mitigated this in Firefox 61 (as noted in comment 10)