Closed Bug 267122 Opened 18 years ago Closed 14 years ago
[SA12979-1] Content-Type not sufficiently validated before display
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. SA12979.zip/1a/poc.php Choose "Open with" and press "OK". A .bat file will execute. SA12979.zip/1b/poc.php Choose "Open with" and press "OK". The attached shortcut (.lnk) will execute.
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+
which versions are affected? (and which products?)
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-
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
see bug 270159. i think this patch should have maybe been ifdef windows :-(
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 Firefox/1.0.1) 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"); header("Content-Type:video/avi"); readfile("winmine.lnk"); 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
sounds a bit like the content header swithching approach used in a defcon talk from last summer http://www.defcon.org/html/defcon-15/dc-15-speakers.html#Schrenk 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.
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 220.127.116.11. 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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.