234416 - can spoof filename in "what should firefox do with this file" dialog

Status: RESOLVED FIXED

(Toolkit :: Downloads API, defect)

Description

[Gabriel Cabillón]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

1) The open file dialog box doesn't show the complete name of the file to
download, truncate it instead of wrapping it.

2) If I choose de "Open with" option without an application selection the OK
button reminds enable and if I click it, open the default application.

I'm telling this in a spoofing file extension name context like this: 
http://secunia.com/advisories/10760/



Reproducible: Always
Steps to Reproduce:
1. Go to http://secunia.com/internet_explorer_file_download_spoof/


Actual Results:  
file name truncate
OK button enable when open with selected ...

Expected Results:  
file name wrapped
OK button disabled

Comment 1

[Mike Connor [:mconnor]]

how do you envision diabling the OK button?  how do we determine what is and
isn't a spoofed filename?

also, I don't know what font sizes you're seeing, but the number of spaces there
aren't big enough.  But its still possible somewhat to spoof.  Although, maybe
it would be possible to forcewrap the text, if there's a way I have another bug
I'd like to have a way of wrapping unbroken strings properly.

Comment 2

[Gabriel Cabillón]

(In reply to comment #1)
> how do you envision diabling the OK button?  how do we determine what is and
> isn't a spoofed filename?
> 
> also, I don't know what font sizes you're seeing, but the number of spaces there
> aren't big enough.  But its still possible somewhat to spoof.  Although, maybe
> it would be possible to forcewrap the text, if there's a way I have another bug
> I'd like to have a way of wrapping unbroken strings properly.
The idea of disabling de OK button is to force the user to make the decision of
choosing the application, to make responsible him.
I understand we cannot determine what is and isn't a spoofed filename, I just
see it like another barrier of security.

The URL example its a case test only, add some spaces or/and increase de font
and you possible have a spoofed name.

About the wrapping thing I saw Mozilla Suite 1.6 do that in the same case.

Comment 3

[Neil Jenkins]

I don't think this a vaild problem for three reasons:

1. The name can be scrolled by clicking and moving the mouse (a poor reason I know).
2. Firefox says " ... which is a
{3050F4D8-98B5-11CF-BB82-00AA00BDCE0B}SECUNIA_INTERNET_EXPLORER%2EPDF file.
Which is obviously not the pdf file its trying to spoof as.
3. Firefox shows no programs to open it with because it does not know what sort
of file it is and defaults to "save".

I recommend resolving this invaild.

Comment 4

[Jesse Ruderman]

IMO, this is a valid security hole.  You only have to successfully spoof an
extension in one place to get most advanced Windows users to use Windows
Explorer's "Open" command, which opens documents and launches executables.

Comment 5

[Neil Jenkins]

I think the bug here is that Firefox offers to open a file when it does not know
the filetype (and hence does not know what to open it with). This should
probably be filed as a seperate bug anyway if it does not already exist. If the
file happens to be an exe file with the name spoofed as shown with loads of
spaces then Firefox already says this is a file of type executable (and as far
as I remember won't offer to open it).

If you still insist the original bug is valid then perhaps the following
approach could be used:

If a name contains more than one consecutive space then shorten these to only
one space. I can't see this breaking anything and it resolves the spoofing problem.

Comment 6

[Mike Connor [:mconnor]]

this would be nice to handle in some way, its valid since a well-behaved browser
should be able to recognize spoofy filenames and guard unwary users against
that, but its not really a high priority to deal with.

Comment 7

[Ali Ebrahim]

taking qa

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

maybe detect > 1 spaces in the file name and collapse to 1? 

Comment 9

[Keith Gable]

(In reply to comment #8)
> maybe detect > 1 spaces in the file name and collapse to 1? 

That sounds to me like it would be the best way to solve this issue. Or, at
least show it with one space in the dialog (i.e. preserve the spaces when it's
saving it).

Comment 10

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch

trims 1+ spaces to 1 space, used for display purposes only
keeps track of a separate value to use for downloading the file so the file
name is preserved

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

br & trunk fixed. 

Comment 12

[Stefan Pietschmann]

looks like it has been fixed on the branch, so could somebody please add the 
fixed-aviary1.0 keyword?

Comment 13

[Justin Kerk]

What's to stop someone from just using alt-0160 non-breaking spaces instead of
"real" spaces? I don't know if you can make Unicode characters show up in there,
but if so, you can do all sorts of mischief like Unicode spaces, sprinkling in
zero-width or invisible formatting characters, etc.

Comment 14

[Joe K00L]

I am not entirely sure that this is a valid point, however I thought it should
be mentioned at least...

What if the spoofed file is not spoofed using space characters?  Would it not be
possible to have a long file name where there are no, or only a single, space
character that could still trigger this issue?

For example would something like the following trigger this issue?

       File__Name__Is__Extremely__Long__Enough__To__Spoof___.pdf.exe

I haven't tested it but it seems like, with a little more work, an attacker
could still easily trigger this issue even if the space characters are
trimmed...  I think that wrapping the file name is the only real solution.

Joe