Closed Bug 267122 Opened 18 years ago Closed 14 years ago

[SA12979-1] Content-Type not sufficiently validated before display


(Toolkit :: Downloads API, defect)

Windows XP
Not set





(Reporter: BenB, Assigned: dveditz)




(2 files)

From tk@ Secunia:

The vulnerability is caused due to the filename and the "Content-Type" header
not being sufficiently validated before it is displayed in the file download
dialog. This can be exploited to spoof file types in the file download dialog by
sending specially crafted headers containing whitespaces, dots and ASCII bytes 160.

Successful exploitation can lead to execution of malware when a user opens a
file through the file download dialog.

-- Example/PoC Windows Platform --
NOTE: Requires PHP support.
Choose "Open with" and press "OK". A .bat file will execute.
Choose "Open with" and press "OK". The attached shortcut (.lnk) will execute.
OS: Linux → Windows XP
Attached file Proof of Concept, ZIP
Flags: blocking-aviary1.0?
Andreas Sandblad (as@ Secunia) is the bug finder.
on the radar to see if we can get a fix for 1.0
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Depends on: 267828
which versions are affected? (and which products?)
Attached patch patchSplinter Review
darin and I worked this out tonight.
there may be additional issues here but the patch presented corrects the most
obvious by appending the file extension suggested by EHAS based on the
content-type when a file with an executable extension file is saved to disk so
that a file sent as: text/plain with a name like "foo.txt     .bat" would not be
saved as "foo.txt     .bat" but "foo.txt     .bat.txt" so that it does nto
automatically run when double clicked after downloading. 
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Keywords: fixed-aviary1.0
Clearing "fixed-aviary1.0" -- the patch here fixes the variant in bug 267123
(both bugs came as one advisory from Secunia).

This one I couldn't reproduce: what version of Firefox were you testing? I tried
0.9.1, 0.10 and the latest
Keywords: fixed-aviary1.0
see bug 270159.  i think this patch should have maybe been ifdef windows :-(
Blocks: 248511
Blocks: sg-ff101
Flags: blocking-aviary1.0.1+
What's the 1.0.1 bug here? I tried the proof of concept again in 1.0 and can't
see anything particularly nasty happen. 
Asa, please make sure we have a test server set up for these test cases.
Assignee: bugs → asa
jay setup a test server for these (thanks, jay!).
For internal folk, the test case is available at http://pine/sa .  After running
tests 1a and 2b, I'm not sure if this bug is completely fixed in Aviary 1.0.1
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050221

1a php:
$spoofed = "contract.pdf";
$ext = ".bat";
$space = chr(160);
$filename = "$spoofed".str_repeat(" ",99)."$ext".str_repeat(".",99);
$mime = "Adobe".$space."Acrobat".$space."Document".str_repeat($space,99)."/";
header("Content-Disposition: attachment; filename=\"$filename\"");
header("Content-Type: $mime");
echo "call winmine.exe";

For 1a, the dialog does not allow the "contract.pdf .bat" to be opened directly
and properly says that is a .bat file (does not show "Adobe Acrobat..." or say
it's a .pdf file).  If you save it, the file still appears to be "contract.pdf"
because of spaces between contract.pdf and .bat in the filename, but Windows
detects it as a .bat file and shows "..." in the Name column.  Which is still a
little spoofy, but at least we don't automatically open it, although a user
could click on it and run the script.  So this looks partly fixed.

2b php:
$spoofed = "movie.avi";
$ext = ".lnk";
$filename = "$spoofed".str_repeat(" ",99)."$ext".str_repeat(".",99);
header("Content-Disposition: attachment; filename=\"$filename");

For 2b, the dialog does allow me to open the "movie.avi .lnk" file with WMP (it
shows that it is an "AVI file"), but the script cannot be executed that way
(since WMP does not know how to run winmine.exe).  However, if I save the file
it is not saved with the .avi extension as #6 suggests.  It shows up as a link
for movie.avi, but actually executes winmine.exe, which is bad.  So for .lnk
filetypes, this is still a problem.  Are we sure .lnk files are handled as
executable files?  If they aren't, I think they should fall into the same
category at .bat.

Has anyone else tested this with recent builds?  Can anyone confirm what I'm
seeing?  Reassigning to dveditz.
Assignee: asa → dveditz
QA Contact: ali → download.manager
sounds a bit like the content header swithching approach used in a defcon talk from last summer

it there a php testing server up anywhere to test this now?

might be a good to add this to one of the test suites.
Product: Firefox → Toolkit
I can't get this to repro on XP (served by Apache2/PHP):

1a) detected as a batch file and handled accordingly
1b) I get an error about being unable to save the file "because an unknown error occured".  Occurs via the PoC or if I click on the lnk directly.  I could only save the lnk if I right-clicked on it and selected "Save Link As...".  So we might still have a bug here but it appears to fail-safe at least.  Or I might have misconfigured Apache...
2a) treated as txt file type, opens with Notepad by default
2b) treated as an AVI and opens with WMP

I'm not seeing a threat with the above scenarios (though is possible that 1b is just another bug and we are getting lucky).

I'm leaving this open for the moment to see if anyone else can get this to work.  If not, we should close it out.
I tested using the Firefox 3 nightly build from 2008102106 as well as  I got the following results:

1a) detected as a batch file and handled accordingly (same as comment 14).  This is valid behavior for both branches.
1b) For 3.0, I am prompted to save the file which is identified as a LNK file.  The file is saved as a shortcut (though my WinXP system is displaying the text file icon).  For 2.0, I get the error Lucas described in comment 14).  This is valid, or at least safe, behavior.
2a) I am prompted to save the file which is identified as a Text Document.  It is not executable and launches with the default text editor.  This is valid behavior for both branches.
2b) I am prompted to save the file which is identified as a Video Clip.  The file is saved as a shortcut and launches with media player for AVI.  This also seems like valid behavior for both branches.

Since it appears that none of the attached testcases are still valid for spoofing attacks, or are at least no longer reproducible, I am going to resolve the bug as WORKSFORME.  Feel free to reopen if you feel the bug is still valid.
Closed: 14 years ago
Resolution: --- → WORKSFORME
Group: core-security
You need to log in before you can comment on or make changes to this bug.