Closed Bug 234416 Opened 16 years ago Closed 15 years ago

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

Categories

(Toolkit :: Downloads API, defect, critical)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: gcabillon, Assigned: bugs)

References

()

Details

(Keywords: fixed-aviary1.0, Whiteboard: [sg:spoof])

Attachments

(1 file)

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
Severity: normal → critical
Summary: lack of clarity in open file dialog box could drive in a dangerous situation → can spoof filename in "what should firefox do with this file" dialog
Whiteboard: security
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.
Assignee: firefox → bugs
Status: UNCONFIRMED → NEW
Component: General → Downloading
Ever confirmed: true
(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.

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.
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.
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.
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.
taking qa
QA Contact: aebrahim
Whiteboard: security → [sg:spoof]
Flags: blocking-aviary1.0RC1?
maybe detect > 1 spaces in the file name and collapse to 1? 
Flags: blocking-aviary1.0PR?
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0+
(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).
Attached patch patchSplinter Review
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
br & trunk fixed. 
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
looks like it has been fixed on the branch, so could somebody please add the 
fixed-aviary1.0 keyword?
Keywords: fixed-aviary1.0
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.
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
Blocks: 248511
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.