+ security sensitive
Actually, is this even a bug in mozilla? 1) only affects IE 2) will probably run stuffit automatically if its enabled (I don't have a mac) 3) This seems to be an issue in stuffit, I think - I'mnot sure what mozilla can do about it, directly. Comments from someone with a mac?
More to the point, will Mozilla/Netscape bear any responsibility? Does this even affect Mozilla users? Seems like it might. CCing a few Mac people.
while i'm sure the problem is more on apple's end, we don't prompt if the user has turned off the "always ask me what to do with this type of file" checkbox in the d/l dialog, correct?
True...it's probably a bad idea to check the "don't ask" box for file types that Stuffit Expander is going to execute automatically. Should we grey out that checkbox for certain file types, the way we grey out the Run button in the download dialog?
Good idea, I'll look into it.
Steve, Bill, could you guys take a look at this? I don't think it's a huge issue, but I want to be sure.
nsbeta1- Before you renominate, please query bugs marked nsbeta1+ keyword with [ADT# RTM] in status whiteboard (where # is a number between 1 and 3) and make sure that this bug is at least as important as those.
This needs another look...
I think Bill Law is the person to address this.
Mitch and I talked about this the other day. First, the seriousness of this exploit is reduced by a couple of factors in respect to Mozilla/Netscape. We don't automatically launch StuffIt Expander so the user sees an alert first. But the user can disable that alert. Secondly, the exploit sample mentioned doesn't work with Mozilla-based browsers because we refuse to "load" the executable on that disk image since web content can't load file: URLs. The auto-execute threat is still real. The fix would seem to be to treat application/x-stuffit content as "executable" and only allow such content to be saved (not opened). I suspect many users would object to that because that would prevent them from opening normal (non disk image) application/x-stuffit content, too. I do not believe there is a way for us to look inside the content to discern whether it is a disk image. My belief is that there are many, many content/application combinations that can do harm and we cannot block all of them. E.g., Microsoft Word documents can do harm but there is no way we can not provide a means of opening such content directly in the application. Mitch wondered whether we could determine whether the request to open the document was initiated by the user and block the automatic opening if it was. I do not know if that is possible (by the time we get to the level of code with which I am familiar, there is no indication of what initiated the request). At the end of our discussion, Mitch said he was going to talk to Rick Potts about that aspect of the problem. I took that to mean he was going to reassign this bug to Rick, but maybe that was just wishful thinking. Comments?
Over to rpotts. Rick, could you have a look? Do you think this requires an urgent fix?
perhaps we could come up with something simpler... like a load flag that indicates the origin of the channel load? even though nsIChannel is frozen, there are reserved bits that we can play with.
Do you mean, a bit that means "this channel load was initiated by a user action?"
exactly. the channel creator should be able to set this bit accordingly.
Maybe for 1.0.1 we should just release-note this: don't allow compressed files to be expanded automatically. Or do you think we need a real fix?
hey darin, i'd thought about the load flag approach too :-) my only concern is whether this is only one 'instance of many' where we will need additional security-related information... so, i thought it might be a good idea to start formalizing the information via a separate interface... if we are confident that this is the *only* extra information that we'll need then i'm fine with a load flag... otherwise, if it would be useful to more contextual information then perhaps we should start flushing out some kind of security-info interface... -- rick
hmm.. another option perhaps.. can the principal provide this security info? that is can we use nsIChannel::owner to do what we need?
I spoke with ADT and Marketing, and the consensus is that we should wait on this one instead of rushing a fix in that may have usability consequences. Removing nsbeta1+.
I'm sure Stuffit can be configured not to auto-execute. This problem is not entirely Mozilla's responsibility, but we should do what we can. Jesse, what do you recommend?
How about an entry in the release notes advising users to turn off the 'auto execute' pref in Stuffit Expander?
I see no 'auto execute' pref in StuffIt Expander 6.0.1 which came with Mac OS X or the StuffIt Expander 6.5.1 which is the version available for download. I have to wonder if somehow these folks didn't get confused by a behavior in IE 5.1.x for Mac OS X where it would automatically decode a .hqx format download (and possibly .bin format) and then tell the Finder to open the result assuming it'd be a .sit file. That was definitely an automatic execution exploit.
In an amazing bit of timing coincidence I happened to discover StuffIt Expander 6.5.1 will automatically mount disk images just before Mitch changed the summary. In my initial reading of the bug I failed to notice mention of the "Mount Disk Images" option (logically in the Disk Images pane of the StuffIt Expander prefs) being a necessary part of the trigger. I still don't think this merits any more effort on our part than noting in the Read Me and release notes that users should turn that option off. And perhaps an evangelism call to Aladdin Systems telling them that they really should reconsider the default setting for that pref. Especially since Apple is talking about extending the behavior of a mounted installer disk image in Jaguar.
Personally, I consider it a big security bug to execute anything automatically from media inserted. Imagine that I have a CD, which a "friend" made for me and which contains a bunch of HTML files or whatever, but it really also contains an autoexecuting trojan. I know that this is the default in MS Windows for several years, and unless I am missing something, this is a big mistake. Same applies for Apple. Could this happen in Windows, too? Is there any application that mounts something (during "opening" it) in Windows that looks like a CD to Windows? E.g. one of those CD emulators? Is WinZip known to be safe? So, in addition to contacting StuffIt, I would apply some conviction to Apple. I'd even do it myself, if somebody gives me [a] good contact[s].
If I understand the bug text correctly, this vulnerability has been publically disclosed for many months. Why is it still closed in bugzilla?
Let's just add a release note telling people to configure Stuffit not to autorun.
Are you really suggesting we put 8 paragraphs into the release notes for this issue?
No, this is intended as an immediate warning to users. I don't think that release notes alone are appropriate for security warnings.
I think that release note is rediculous. There's no way I'm letting that into our already too long release notes. Come up with two sentences that describe the issue and then we can talk.
how about posting the full text of the problem description elsewhere? then we can include just a link to the full text from the release notes. the release notes could have a one or two sentence summary of the problem with a pointer to more information for the curious reader.
In relation to comments 30-33, how about one paragraph? "In combination with StuffIt and QuickTime, it is possible for untrusted applications to be started from downloaded disk images (files with the extension .dmg in their name). Until a better solution is put in place, it is suggested that users disable the autostart feature in Quicktime."
"In combination with StuffIt, QuickTime and downloadable disk images (.dmg files), it is possible that untrusted applications are automatically started from a website. It is suggested that users disable the autostart feature in Quicktime."
Just how does someone disable the autostart feature in Quicktime? I've been looking for a way to do that since Apple started shipping .dmg files with auto-start installers on them, because I knew that was a bad thing when they started doing that. There apparently is no such option in the OS X version of QuickTime (I can't find it anyway). I remember very clearly seeing that option in the classic version of QuickTime, but it's not there on OS X, either in the QuickTime Player application preferences or in the QuickTime preference panel in the System Preferences.
Dave is right, QT in OS X lacks an option to disable automagic opening of a movie when a volume is mounted. We need to change the recommendation to disabling the automatic mounting of disk images by StuffIt Expander. Especially since Apple has now expanded the functionality of disk images so they can actually install software on your machine when they're mounted.
Actually, watching the process, it appears to be done by DiskCopy itself while it's mounting the image (Stuffit Expander just passes the dmg file off to DiskCopy after it finishes). But I don't see a preference to disable it in DiskCopy, either.
bug owner needs to be updated.
The StuffIt Expander pref UI for this is pretty obvious - the Disk Images pref pane has a Mount Disk Images checkbox we need to tell the user to turn off
Giving to Mitch for now.