Mozilla favors writing/executing on harddisk, using .hta files

RESOLVED FIXED in mozilla1.6alpha

Status

Core Graveyard
File Handling
--
critical
RESOLVED FIXED
14 years ago
10 months ago

People

(Reporter: Bernd Heinze, Assigned: Biesinger)

Tracking

({fixed1.4.2, fixed1.5})

Trunk
mozilla1.6alpha
x86
Windows 2000
fixed1.4.2, fixed1.5
Bug Flags:
blocking1.4.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:fix])

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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.
ok... taking
Assignee: file.handling → cbiesinger
Status: UNCONFIRMED → NEW
Ever confirmed: true
Created attachment 132136 [details] [diff] [review]
patch
Attachment #132136 - Flags: superreview?(darin)
Attachment #132136 - Flags: review?(dougt)
(Reporter)

Comment 3

14 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".
No, that doesn't work either. The checked file extension is the final one, which
is also .hta in this example.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.6alpha
Comment on attachment 132136 [details] [diff] [review]
patch

sr=bzbarsky
Attachment #132136 - Flags: superreview?(darin) → superreview+

Updated

14 years ago
Attachment #132136 - Flags: review?(dougt) → review+
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
Last Resolved: 14 years ago
Resolution: --- → FIXED
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

14 years ago
Is it already too late for 1.4.1?
to my knowledge, it is.

Updated

14 years ago
Flags: blocking1.5?
Flags: blocking1.4.2?
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

14 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+
looks like brendan already checked this into the 1.5 branch
Keywords: fixed1.5
Yes, sorry -- thought I updated this bug (I switched machines and may have left
a bugzilla login screen up).

/be

Updated

14 years ago
Flags: blocking1.5?
Opening.
Group: security
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+
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
Keywords: fixed1.4 → fixed1.4.2
Whiteboard: [sg:fix]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.