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?
Created attachment 119134 [details] The message containing the virus 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
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
Removing confidential flag from resolved WFM bugs
You need to log in before you can comment on or make changes to this bug.