Timeline of Mozilla shell: Security VulnerabilityFriday July 9th, 2004Adam Sacarny writes: "I have created a timeline of the latest security bug. It shows how quickly the Mozilla developers handled the problem, tracking from the first mention in Bugzilla to the last CVS commit to the webpage. Readers get a peak into how development works over at mozilla.org, in particular into how security issues get resolved." We reported on the Update: Adam, author of the timeline, has written a followup post with further commentary on the bug and its fix. One of the things that many people don't seem to understand is that the virtue of Mozilla and free software in general, is not that all free software and open source is absolutely flawless and perfect. There have been instances where Mozilla has had security vulnerabilities before (just as every software has). But the virtue of Mozilla is that since the code is free for everyone to use and modify, these vulnerabilities are quickly fixed, even sometimes before crackers have an opportunity to exploit them. This is what makes free software and open source software very secure and very reliable. Apparently the author of the article "Mozilla Security Nightmare Begins", Jay Wrolstad, doesn't understand the dynamics of free software and open source and creates almost an alarm where there is none. Although he mentions the fact that the patch is already available, he neglects to mention that such a patch was available very quickly, even far more quickly than the speed in which Microsoft provides its patches to Internet Explorer. According to Newsforge, it took just a minute (about 60) seconds for the patch to be available to the public: http://software.newsforge.com/software/04/07/08/2327246.shtml . So .... please Mr. Wrolstad, don't create unnecessary alarm where there is no problem! Unfortunately, that isn't the problem. The timeline is quite fascinating, but the issue isn't racing against the hackers -- it's racing against the end-users. Most MS security issues are been patched days, weeks, or even months before the first real-world exploits start to trickle in, but confusion, laziness, and outright miseducation on security issues keep these patches from being deployed as they should. If Mozilla wants to stay ahead of the game, not only do they need to get the update engine up and running, it needs to silently install security updates by default. There's always a potential risk to pushing unattended patches, but it beats the alternative. This major exploit has really burst everyone's bubble about Mozilla being impenetrable; ActiveX notwithstanding (which, admittedly, is half the problem), it's no more inherently secure than IE, and Mozilla are no more or less capable in the grand scheme of things of deploying patches than Microsoft (who has a superior mechanism to do so at this point). Now that Firefox is starting to move into position to compete, we're going to see this a lot in time. This is actually a good thing, because it will cause advocates to shift away from arguments that often seem intangible to common end-users (security), and towards the better overall experience that Gecko products can bring everyone. Leet me remind you that the problem is initially a Windows problem. Shell: is inherintly insecure. Mozilla mistake was only to allow it to the world. This bug is not present on non Windows plaftorms. > Leet me remind you that the problem is initially a Windows > problem. Shell: is inherintly insecure. Mozilla mistake was > only to allow it to the world. Hmmm... Just "shell:"?!? I think that at least some folks would say that the whole idea of blacklisting protocol handlers (as opposed to whitelisting or more radical approaches) was a ticking bomb from the get-go (and known as such for about two years)! "shell:" [kind of] exploded now, though luckily [so far] it seems like it went off in a desert. Next time things could get way worse... And protocol handlers are NOT just a Windows problem -- although it's likely exacerbated by the fact that permissions are generally more lax with Windows users, a consideration that must be taken into account when developing general-use Win32 network apps. But that wasn't the point I was trying to make, anyway. The point is that turn-around time on patches isn't that significant in a home user environment, and that now is the time for advocacy to start looking in new directions. I graphical timeline would be more helpfull :D Unfortunately I don't have the drive or the skill to make a graphical version. (Well. I could try. It just might be squintworthy) If you or someone else would like to make a graphical version, I would gladly link to it or host it. Adam The security timeline just got added to my list of "evangelistic materials" for Firefox and Thunderbird; that's the kind of thing that we should really hammer in the media and every other chance we get... RW I don't understand all this bragging about "how good we are" in fixing security problems. Since the seeds of this bug were "red-flagged" by some users 2 years ago, and Mozilla failed to properly understand the implications then, we all should be sheepish now. And fixing by just blocking the "shell" preference will lay the foundation for the next external protocol exploit to come. See for reference: http://bugzilla.mozilla.org/show_bug.cgi?id=167475 and http://bugzilla.mozilla.org/show_bug.cgi?id=163767 and the comment by ROC at http://bugzilla.mozilla.org/show_bug.cgi?id=250180#c7 I completely agree. It seems pretty obvious that Mozilla.org knew this was a potential security hole as of 2002-09-09. Naturally, I'm glad that it was fixed so quickly after a specific exploit was released, but if this was MS and they knew about a problem for almost two years and did nothing, we all know what would be all over the front page of slashdot right now. If Mozilla Org wants to get ready for the flood of FF 1.0 users, they should announce security fixes that garner wide public review on www.mozilla.org main page, or at least on Support's main page. I spent 5 minutes looking for it, pretending to be Joe The User who just wanted to know if his FF browser is vulnerable, and could not find any reference to it. The Release Notes under the FF0.91/0.92 heading on the home page only refer to 0.9 great features... This exploit is STILL in Internet Explorer. I have a fully updated version and was able to exploit it using the methods described here / in the bug report. Just a heads up, glad I don't use IE for anything :) I don't see any evidence that IE would execut arbitrary code as they claimed Mozilla would. In fact, when I try to open an known executable, it prompts me to download or open the executable. The concern with Mozilla was that it would auto-execute the program with the arguments given to it by the website (the arguments make the exploit dangerous). IE apparently does not allow this as it probably used to. Though this is a mozilla board, there is no reason to make shit up. Either show us the exploit or shut up. Telling me to shutup was a bit uncalled for, if you wanted to find the page that showed the exploits you could easily, as it only took me a few minutes to find the page. I said to look in the bug report, since thats where I had found this link. I didn't to post it do to it not being on my site, and it could be used by other people to make bad exploits. But here is the link: http://www.mccanless.us/mozilla/mozilla_bugs.htm Try it in IE, you'll notice that the links work, and it is able to load files off your computer. Yeah, it does work. "shell:windows\notepad.exe" opens notepad straight up. This is on both my main computer, running the latest RC of SP2, and on my fully-patched SP1 box. This is not an exploit!!! You can't do it remotely - that's the point. If you could pull this off remotely, then it would be an exploit. This is like saying that going to the Start Menu/Programs/Accessories/Notepad is an exploit. But the point is that it can be done remotely. You can put a link on a webpage titled 'Get free porn here!' or whatever, and when people click it, it loads Notepad on their computer. If you don't think Notepad is all that scary then I suppose maybe you could imagine it loading: rd /s /q "c:\documents and settings\my documents" Now if you think a situation where somebody can click a harmless-looking link (or go to a page that has an iframe, not needing to click a link at all) and have it delete their entire documents folder without warning isn't a security hole, then, um... I don't know whether this is doable remotely in IE, I can't be arsed to set up a test page, or whether that particular command would work in either case (rd specifically would not be available using the shell: protocol, since it's a shell builtin command not an actual program, but there are programs that do similarly nasty things) - but this is the *type* of thing that would've been possible with Mozilla before the hole was fixed. --sam Yeah, I forgot about IE also being Windows Explorer for a bit there, so anything typed into the address bar acts as if it was done in Win Explorer instead. If done through a web page then on SP1 it acts as if it's on a remote site, giving the download box for whatever program you link to or it handles HTML as part of the website. On SP2, it acts as if the download is remote but the test links for other local things on http://www.mccanless.us/mozilla/mozilla_bugs.htm don't work at all. Much better than I thought.. Why does this kind of functionality exist in Mozilla in the first place? Toooo much integration with the OS is what has caused/is causing a lot of problems with IE. So why are the Mozilla developers doing the same with Mozilla? This makes me wonder now what other protocol handlers are implicitly enabled and coded into Mozilla which can cause headaches. Simply said: shouldn't a browser be handling the file:, http:, https:, ftp: protocols only (plus javascript)? If I want my browser to handle other stuff, I should be required to add it explicitly through an installable extension and/or plugin. Well, what it looks like to me is that Mozilla linked to an API / windows feature that can grow infinitely in functionality. When this was first implemented either shell: wasn't around or not on enough computers for people to notice. Finally somebody pointed out how this could be exploited. Unfortunately the "correct" fix to this matter is a matter of philosophy. Blacklisting "shell:" doesn't prevent some other faulty or dangerous external protocol handler from popping up in the future, yet some protocol handlers can be useful. Personally I think there should be a blacklist of known bad ones in addition to a warning message for any new or unknown ones, something to the effect of "/!\ You are about to launch an external protocol handler for the protocol whaterverprotocol:, this may be dangerous. Are you sure you want to launch the external handler? [ ] don't show this message for this protocol next time. | Yes | | [NO] |" Note that this cuts both ways. A lot of people, here and elsewhere, were unhappy that Mozilla ignored their system "mailto:" handler setting. Is the end user expected to set up a protocol handler (say "ssh://" or "news:" or "rtsp://") for every single program they use? That seems a little silly (but probably is the situation normal on Unix). When the recent Mac/Safari protcol handler bug came out, there was some actual _productive_ discussion on this topic rather than pointing fingers at Windows or IE or whatever. One point made was that the API (or registry) should indicate whether the protocol handler is "safe" or not to launch from a webpage. It is not enough to create a patch for a security hole. One must then distribute the patch quickly and to all users, including the technophobes and the people on restricted corporate PCs. I clicked the Firefox button in the upper-right corner of my browser and was taken to the Firefox product homepage. Where there was no information whatsoever about the hole or the patch and no obvious link to an appropriate support and update page that might have it. "(according to Bart Decrem, the author of the article did contact the Mozilla Foundation for comments but they lost his number and could not return the call)." Perhaps I'm a curmudgeon, but this dismays me. For Mozilla based browsers to truly succeed in the market, we need to gain mind-share among corporate users as well as folks at home. I use Mozilla as my default browser at home, but on desktops at the office, the standard is IE. *I've* installed Mozilla there on my machine, too, but I'm on the IT staff. The vast majority won't switch unless management make a decree that henceforth the standard shall be Mozilla. (And even if they want to, most users have Win2K boxes with policies that won't *let* them install thier own software. Me or one of my peers must do it for them.) For that to happen, Mozilla *must* have better marketing. It should be *somebody's* job at the Mozilla Foundation to deal with stuff like this, and when a member of the press calls to get comments on an upcoming article, the number should *not* be lost. I'd say this is something the Foundation's newly hired product manager needs to address ASAP. ______ Dennis You are indeed a curmudgeon. ;) We're all human, so mistakes will be made, including losing phone numbers. No, I don't accept the argument that any particular individual mistake is unacceptable. Although I'm sure the story about the IBM VP who made one mistake, which cost $20m, who wanted to resign, and who was told by his boss "no way am I going to let such a good VP resign when I just spent $20m training her" is apocryphal, it makes a good point. The more important issue is honesty. Do we have a group that is prepared to be honest? I was heartened that Bart made no bones, right from the get go, that he (or at least someone) had made that mistake. You can bet he's on the case to try to stop it happening again. love raiph the browser wars are beginning-we have to expect Microsoft and friends (there are a lot of people who will lose if people leave IE) will get nastier and tougher. Everyone will be looking at Mozilla with a microscope and a fine toothed comb so be prepared Mozilla's track record has been consistently better than Internet Explorer's at security. That doesn't mean perfect; it means better. Microsoft & Co. have a long way to go towards cleaning up their own software security issues, and in the meantime, Symantec and McAfee will make a pile of money off Microsoft's software. How much money does Symantec and/or McAfee make off Mozilla Foundation products? #30 Misleading NewsFactor Article "Somewhat" Correctedby peterlairo Wednesday July 14th, 2004 1:31 AM NewsFactor had a completely misleading headline called "Mozilla Security Nightmare Begins" http://enterprise-security-today.newsfactor.com/story.xhtml?story_id=25807 The article is reproduced on YahooNews and most readers have written furious reviews about the POOR JOURNALISM: http://story.news.yahoo.com/news?tmpl=story&u=/nf/20040709/tc_nf/25807&e=3 Today NewsFactor released another article that seems an attempt at backtracking from their previous blunder, called "Mozilla Browser Flaw: Is Windows To Blame?" http://www.newsfactor.com/story.xhtml?story_id=25835 Unfortunately, this new article's headline is much weaker, and even creates "uncertainty" an "doubt" (as in FUD), and they still refer to it as a "Mozilla Browser Flaw". It seems Mozilla.org will need some agressive strategy to deal with this misleading articles. I suggest high level (Mitchell,...) talks and pressure, as well as letting the user base know how to help (e.g., scathing reviews). |