1279126 - Save hidden executable in users computer using 'Save Page As'

Status: REOPENED

(Firefox :: File Handling, defect)

Description

[Abdulrahman Alqabandi]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36

Steps to reproduce:

If we reference a .exe using a link tag like:

<link rel="stylesheet" href="http://localhost/calc.exe" />

then we have the user 'CTRL+S' (save page as) and by default (I believe) its set to 'Web Complete' 

Tested on latest nightly. Also looks like google chrome has the same behavior, does not look like a safe and expected behavior.


Actual results:

You will notice that in the folder 'index_files' calc.exe is there in full.

The only danger here is if the user opens the file himself. Or if in the future there was some sort of exploit that requires there to be an attacker controlled binary present.

We can potentially also have a .lnk or .url file be downloaded as well which point to the executable and have the user open our URL file by telling them this is where our website is or something. Successfully executing the application.


Expected results:

I think its best to not save files if they are not legitimate. Like, in this case there should be some sort of check to see if the files being saved are safe content types and prevent them being saved.

Comment 1

[Abdulrahman Alqabandi]

According to Google, this is a known issue.

Comment 2

[Abdulrahman Alqabandi]

Also note that we can also save external pages (then read them once the page is saved and opened locally) with something like:
<link rel="stylesheet" href="https://www.facebook.com/"/>

Comment 3

[Abdulrahman Alqabandi]

Also.. We can reference any file within a users local computer in an attacker controlled website like:

<link rel="stylesheet" href="file:///C:/secret/secret.txt"/>

and if the user saves the web page (web complete by default) and open it locally we will be able to read said file.

Comment 4

[Abdulrahman Alqabandi]

I think its important to note that the reason google chrome wont fix this is because of one main difference between chrome and firefox. That is when it comes to the File:// URI scheme, in firefox we can read any files within the same directory as the opened local document whilst in chrome this is blocked by SOP.

Comment 5

[Abdulrahman Alqabandi]

Attachment: PoC which saves file list of C:// and contents of facebook.com

Open this PoC then hit CTRL+S and save web page complete. Re-open and you should see that both textareas were filled up with sensitive information.

Comment 6

[Abdulrahman Alqabandi]

Attachment: Result of using the PoC

Comment 7

[Abdulrahman Alqabandi]

Can you check to see if the component I chose is correct please?

Comment 8

[:Gijs (he/him)]

(In reply to Abdulrahman Alqabandi from comment #7)
> Can you check to see if the component I chose is correct please?

I think the component is fine.

Comment 9

[Abdulrahman Alqabandi]

Any update on this? Confirmation and/or security rating?

Comment 10

[Abdulrahman Alqabandi]

Looks like this is sort of a dupe of Bug 332676

Though it does not mention that you can also save and read arbitrary files. And the report was back in 2005 (wow) and its not private.

Comment 11

[Abdulrahman Alqabandi]

I just realized its also possible to instantly gain access to the saved files, if we instead of having the victim save the file on their local disk, but have them copy paste a publicly shared folder (like file:\\evilHost\booom\a.html).
As far as the victim knows they are only saving one file, little do they know all of their data is being sent to an evil host.

Would this fact make this bug a tad bit more severe? Also, correct me if im wrong but network enabled folders can be access via the internet as opposed to intranet only?

Comment 12

[:Gijs (he/him)]

(In reply to Abdulrahman Alqabandi from comment #11)
> I just realized its also possible to instantly gain access to the saved
> files, if we instead of having the victim save the file on their local disk,
> but have them copy paste a publicly shared folder (like
> file:\\evilHost\booom\a.html).
> As far as the victim knows they are only saving one file, little do they
> know all of their data is being sent to an evil host.

Can you elaborate on how this scenario would work? It's not clear from your description. Copy paste what - a link, or the actual folder? In Firefox or their file manager? Wouldn't they still need to open it in Firefox for any script to run?

Comment 13

[Abdulrahman Alqabandi]

(In reply to :Gijs from comment #12)
> Can you elaborate on how this scenario would work? It's not clear from your
> description. Copy paste what - a link, or the actual folder? In Firefox or
> their file manager? Wouldn't they still need to open it in Firefox for any
> script to run?

Using PoC from comment 5:

Press CTRL+S (open prompt to save file as.) Instead of having the user be instructed into only saving the page, we also tell them to copy paste 'file:\\evilHost\booom\a.html' first. 
'evilHost' is supposed to be a remotely available shared windows folder. So after the user attempts to save, it will put the files into the remote windows folder which is attacker controlled. 

Note that this is a Windows API, so I am not sure if it will work on non windows. I also think this may be done using remote FTP server. Will test that.

Comment 14

[Abdulrahman Alqabandi]

Doesn't work with ftp

Comment 15

[Daniel Veditz [:dveditz]]

In all important particulars this is a dupe of bug 332676. Slurping in other local files is bonus information but doesn't make this any worse, and in any case the fix is the same: tighten our local file:// rules the way chrome has.

Getting someone to save a file on a remote server is bad with or without the remote-file-inclusion trick (it could be their bank account information page), but no, it doesn't make this bug any worse because it's so unlikely to convince someone of that. If they're that gullible just have them do something worse like download and run malware directly.

Comment 16

[Daniel Veditz [:dveditz]]

One aspect of this bug that's not explicitly mentioned in bug 332676 is the very first part of this summary: the ability to stuff malware executables or other unwanted files on a user's disk. I feel like that was mentioned long before this bug but I couldn't find an instance, so this one will do for now as a placeholder. People keep bringing this aspect up, though it's not all that clear how that hurts a user. The saved web page isn't going to be able to launch it, and it won't be incorporated into the saved page. Sure, it's there on the disk, but how likely is it that a user will be digging around in obscure sub-folders and decide launching a random executable is a good idea?

Over in bug 395752 comment 15 Gijs said

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

<img src="file:///foo"> should be a broken image, we shouldn't be making
copies of things we don't let you link to in the first place!

This is now fixed as a result of bug 1469916.

I may have obscured my meaning by using a file: url. If I have a page with an image like:

 <img src=https://bugzilla.mozilla.org/attachment.cgi?id=280444>

My document will have a broken image because that attachment (from bug 395752) is not a valid image. But if I save the page "complete" the _files subfolder will still end up with comp1.html in it. When I do something similar with script or a stylesheet I get an error in the console about the mime type mismatch and nothing gets saved. That seems a better behavior.

But of course a malicious server could give malware.exe the right MIME type for the context and not worry about any parser errors. Not sure if that would still save the file but I assume so (I think that would be equivalent to the <img> case). Not sure if there's a generic way to track which loads throw an error and refuse to save those without retrying.

Comment 17

[Daniel Veditz [:dveditz]]

But of course a malicious server could give malware.exe the right MIME type for the context and not worry about any parser errors. Not sure if that would still save the file but I assume so

It does save a script if the MIME type isn't rejected, as seen in bug 1771741.