Closed Bug 200189 Opened 21 years ago Closed 21 years ago

Possible auto-execution of disguised .exe attachment

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: security-bugs, Assigned: security-bugs)

Details

Attachments

(1 file)

The message containing the virus
209.79 KB, text/plain
Details 
A user claims to have received a virus message in Netscape Mail which downloaded
and executed automatically. It's a two-part message. The mime-type of the second
part is audio/x-wav, but the file extension is .exe. I tried this locally but
can't reproduce it yet - the attachment is not executed. Here's the original
message:
---------------------------------------------------
I recieved an email that had an attachment of mime
type audio/x-wav. The attached file was name="eCDrCiRhA.exe"

when trying to open this in the netscape mail viewer
immediately started to execute the program which
started to run an installer.

There are two issues here. First, netscape shouldn't
launch the media viewer without any user options.
Second, nothing should *execute* a file without
checking to see if the file type makes sense
compared to the mime type.
I couldn't find any way to disable this feature,
including removing the x-wav keys from the registry. 
----------------------------------------------------------

In a followup message, the user said he has no helper applications configured in
Mozilla prefs. We store the "download this file type and don't ask me again"
prefs in Mozilla prefs, not the Windows registry, right? Do we execute
attachments using ShellExecute regardless of MIME type?
Warning: this attachment does in fact contain a virus, so download at your own
risk.
I can't get this file to execute automatically, either from mail or browser, no
matter what I do. If I associate audio/x-wav with Winamp, in prefs, then Winamp
will open the file but won't be able to play it since it's an exe. Someting else
must be going on here.
Did this user happen to mention the mozilla version being used?  Netscape 7.x, I
assume?

To reply to the other stuff:

> First, netscape shouldn't launch the media viewer without any user options.

We never do that without prompting once for that type.

> Second, nothing should *execute* a file without checking to see if the file
> type makes sense compared to the mime type.

We have such checks in at least two places; not including the last-ditch check
before the ShellExecute() call....

> We store the "download this file type and don't ask me again" prefs in Mozilla
> prefs

Yes.

> Do we execute attachments using ShellExecute regardless of MIME type?

Yes, but see
http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/win/nsOSHelperAppService.cpp#85
(this is where we call nsILocalFile::Launch, which calls ShellExecute on Windows).
As a note, we _did_ use to have a vulnerability along these lines, but I _think_
we fixed it on the 1.0 branch....
This looks like a long known outlook bug.
Is it possible that the user has unchecked "always ask before opening this type
of file" when opening wav files previously?
IMHO the check in 
http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileWin.cpp#1772
does not always return correct value.
From the black list at least the ".hta" and the m$ Access extensions are
missing, which are definitely equivalent to executables.
I can open .hta attachments (which are equivelant to executables) from email.
But can't reproduce variations of these exploit on Win2K.
George, many things are equivalent to executables:  .doc, .pl (if your helper
app is the Perl interpreter), the ones you mention.  That test is trying to
detect file types that ShellExecute will just execute directly no questions
asked.  This is why it does not check .doc, eg -- that's a problem with the
helper app, not with the file type per se.

I don't know much about the extensions you're talking about; if you feel that
they should be considered executable please file a separate bug to that effect;
adding things to the list is trivial.  ;)
I am not sure whether the .hta file I opened is executed via shellexecute or a
helper application.
Just to comment in the bug that .hta can do the same damage as .vbs or .exe can
for sure. .hta is builtin into windoze for sure.
Have the impression that the purpose of the check in nsOSHelperAppService.cpp is
to protect users when they do silly things like opening attachments.
If I am getting this right, you are protecting silly users from builtin windoze
functionality but not from additional m$ silliness like word, access, .NOT, etc. :) 


We're not protecting _silly_ users.  We're protecting smart users.  There is no
way to protect silly users short of completely disallowing direct opening of
attachments or other content; and all that does is forces them to save it before
they just open it anyway.  A _smart_ user, however, would disable the dangerous
aspects of Word, so .doc files would be safe.  The same smart user cannot
disable the fact that ShellExecute() on a .exe file will run it, however -- not
an option under Windows.
I think the isExecutable blacklist is a separate issue. The issue here is making
sure we don't blindly call ShellExecute on an .exe disguised as audio/x-wav.
When I tried this, even with the "always ask me" flag unchecked, we try to open
the file using the chosen helper app, which of course does nothing. I can't
reproduce the behavior the reporter described.

Georgi, it sounds like you can't reproduce the problem either; is this correct?
Boris, can you give it a try?
I tried something very similar (replacing the virus with harmless exe) and can't
reproduce the behavior the reporter describes.

IMHO this looks like an exploder worm. In case it affects netscape, I believe
much more users will notice.

Mitch, I don't have a windows system to test on.
This looks like nimbda, which was from long ago.
A quick search for +"audio/x-wav" +outlook
Returns this in the first page:
http://admin.do.tn.tudelft.nl/nimda/nimda.html
How Nimda attacks your webbrowser
For what it is worth, I tried to reproduce this using a mozilla trunk build
yesterday and I encountered the same findings as Mitch. We kept giving the
content to the helper app which then did nothing.
Since no one was able to reproduce this, I'm resolving Worksforme.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Verified
Status: RESOLVED → VERIFIED
Removing confidential flag from resolved WFM bugs
Group: security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: