Bombarding the user with incorrect, jargony warnings rarely improves security. It also leads to "dialog fatigue", which reduces security in the long run.
This problem is identical to a serious vulnerability recently discovered in Safari where a nafarious site could make use of the disk:// URI handler and the default automatic custom URI installer to download and execute arbitrary code. Has anyone checked to see if Mozilla/FireFox are also vulnerable to this?
They were, until the problem was worked around in Firefox and fixed in Mac OS X.
As several people on Full Disclosure pointed out to you, you misunderstood the original vulnerability: the Microsoft products you cite raise a warning dialog when you traverse the link by hand.
(I didn't see anyone say that on Full Disclosure.)
You're wrong. Neither of the programs I tested raised a warning dialog. A newer version of Word does, though, as pointed out by several Slashdotters.
In neither case does the link "self execute" -- you need to ation on it to cause the problem.
The only action required in both programs is activating a link. Activating a link is supposed to be safe.
Chasing a link that raises an error box, and then clicking "OK" -- that's stupid and dengerous.
Depending on the wording of the warning dialog, it might not be stupid.
If the warning is 100% jargon, as in "This link uses the shell: protocol. Do you want to proceed?", only someone very geeky or very paranoid would click Cancel. I think AIM or Gaim or Trillian has a dialog like this.
I said "usually". We did great with the shell: hole, but we had to because we found out about the hole at about the same time the hole was posted publicly on Full Disclosure. Most security fixes for bugs found by Mozilla community members do not result in security-fix releases (e.g. 0.9.2); the fixes are just checked into CVS and included in the next release (e.g. 0.8, 0.9, 1.0).
I did not contact Microsoft before posting on Full Disclosure. I thought posting to Full Disclosure would encourage Microsoft to fix the hole in Windows rather than forcing every software vendor to work around it using a whitelist or blacklist. Maybe I was wrong about that. I felt that all software vendors should be given an equal chance to fix the hole if they want to be safe running on unpatched versions of Windows. I was frustrated that Mozilla looked bad because of a Windows hole that affected a large number fof programs.
I got an IM from someone at Microsoft thanking me for the post on Full Disclosure. Microsoft earned a little respect from me today.
I'm the one who posted this message to Full Disclosure. I was too lazy to test all popular e-mail clients, IM clients, word processors, etc. that run on Windows, so I posted after finding only two vulnerable programs. Who wants to help?
All you have to do is see if your programs accept links to shell:windows\notepad.exe. If clicking the link launches Notepad, it's vulnerable. If there's a warning dialog, it's somewhat vulnerable, depending on the wording of the dialog.
Can I Fax a Thank-You Note? (1998) covers phones, cell phones, beepers, fax machines, e-mail, IRC, and usenet. It is both funny and full of useful advice.
Excerpt:
Everyone deserves a greeting
Have you noticed how impolite people are on the phone? You sweetly answer your phone: "Hello?" You're greeted with "Yeah. Let me talk to Billy," or "Uh, I was callin' about the tickets," or "Is Sherry there?"
The person answering your phone call at the very least deserves a hello. If you are acquainted with the person answering the phone -- even if you just know his name or have only spoken with him on the phone -- you should try to greet him with a sentence. This is equally important in social and business situations. Say you're calling your friend Liz and her husband, George, answers the phone. Depending on how close you are with George, you may say, "Hi, George, it's (your name). How are you?" or something like that. It is rude simply to say, "Hi George, it's (your name), can I speak to Liz?" George desrves a polite social interchange.
Another excerpt:
No one
ever wants to hear your beeper. Beeping mode should not exist. In fact, the only reason it does exist is so that we don't have to call them vibrators.
Why would a program register a protocol called FormatUserHardDrive: ? When a program registers a protocol, it's telling web browsers to send those links to that program.
That's not a report of this vulnerability. It's a comment about a proposed change that might have prevented this vulnerability, had it been implemented. At the time, there was no known actual vulnerability that demanded the change.
The proposed change wouldn't even have prevented this vulnerability. It would have increased the requirement to exploit it from "Get the victim to visit your site" to "Get the victim to visit your site and click a link".
Eweek and Slashdot linked to bug 167475, implying that Mozilla developers knew about this hole in 2002. Fixing bug 167475 would have done approximately nothing to protect Mozilla users against the shell: hole in Windows, and that is why bug 167475 hasn't been fixed.
The correct bug number for this hole is bug 250180.
The text-to-speech form comes from AT&T (very very natural sounding, I might add) -- it's a post form, so I had to use the new-window trick in the bookmarklet.
Have you tried treating the POST form as a GET form? In some languages, the default is to accept both.
If the site only accepts POSTs, or if you might select a block of text too long for GET, you can create a hidden <iframe> instead of a new window and post from there.
I'm intrigued by your "a:not([href^="javascript:"]) { display: none }" comment -- what is this "edit styles" you mention?
I also think that a three second delay is both arbitrary and unsafe. There are plenty of hunt-and-peck typists that would look at the keyboard for three seconds trying to find the 'l' and 'y' keys.
I hadn't thought of hunt-and-peck typists when I suggested the delay. You're absolutely right.
I don't have a better suggestion, except perhaps bringing the confirmation up in a popup that doesn't steal the focus. I don't think a website can trick somebody into switching windows and hitting 'y'.
That would be annoying, since you'd have to focus the window manually, and wouldn't solve the double-clicking version of the attack.
I'm liking a suggestion by Microsoft more and more. The suggestion is to show a new toolbar instead of the security dialog when a site tries to install software. Clicking the toolbar brings up a normal security dialog with a complete warning and Install/Cancel buttons. Since installing software would then involve going through browser chrome, it would be more difficult for sites to make you accept the software installation dialog without your consent.
Not only would a toolbar be more secure, it would also be less annoying. Users don't like to wait. I suspect users don't like to wait for the same reason that users prefer keyboard interfaces even when they are slightly slower than mouse interfaces, and for the same reason that I spend an hour writing a program to do something for me that I could do myself in ten minutes.
Did you make the text-to-speech bookmarklets? They are cool, but it would be nice if they used location= with GET or an iframe instead of a new window.
P.S. I used edit styles and typed
a:not([href^="javascript:"]) { display: none } to see just the bookmarklets on your bookmarks page;)
Slashdot Mirror
Bombarding the user with incorrect, jargony warnings rarely improves security. It also leads to "dialog fatigue", which reduces security in the long run.
If they had implemented a whitelist of known-good URL schemes back then, it would have been a proactive security measure.
And it would have broken a large number of programs. What's your point?
This problem is identical to a serious vulnerability recently discovered in Safari where a nafarious site could make use of the disk:// URI handler and the default automatic custom URI installer to download and execute arbitrary code. Has anyone checked to see if Mozilla/FireFox are also vulnerable to this?
They were, until the problem was worked around in Firefox and fixed in Mac OS X.
As several people on Full Disclosure pointed out to you, you misunderstood the original vulnerability: the Microsoft products you cite raise a warning dialog when you traverse the link by hand.
(I didn't see anyone say that on Full Disclosure.)
You're wrong. Neither of the programs I tested raised a warning dialog. A newer version of Word does, though, as pointed out by several Slashdotters.
In neither case does the link "self execute" -- you need to ation on it to cause the problem.
The only action required in both programs is activating a link. Activating a link is supposed to be safe.
Chasing a link that raises an error box, and then clicking "OK" -- that's stupid and dengerous.
Depending on the wording of the warning dialog, it might not be stupid.
If the warning is 100% jargon, as in "This link uses the shell: protocol. Do you want to proceed?", only someone very geeky or very paranoid would click Cancel. I think AIM or Gaim or Trillian has a dialog like this.
If the warning says "Hyperlinks can be harmful to your computer and data. Do you want to continue?", many users will think "Huh? Hyperlinks have to be safe; I click them in web pages all the time." and click OK. Word 2003 has a dialog like this and doesn't show it for "safe" protocols.
I said "usually". We did great with the shell: hole, but we had to because we found out about the hole at about the same time the hole was posted publicly on Full Disclosure. Most security fixes for bugs found by Mozilla community members do not result in security-fix releases (e.g. 0.9.2); the fixes are just checked into CVS and included in the next release (e.g. 0.8, 0.9, 1.0).
Fixes for Firefox security holes usually don't get into the hands of users until the next release :(
I did not contact Microsoft before posting on Full Disclosure. I thought posting to Full Disclosure would encourage Microsoft to fix the hole in Windows rather than forcing every software vendor to work around it using a whitelist or blacklist. Maybe I was wrong about that. I felt that all software vendors should be given an equal chance to fix the hole if they want to be safe running on unpatched versions of Windows. I was frustrated that Mozilla looked bad because of a Windows hole that affected a large number fof programs.
I got an IM from someone at Microsoft thanking me for the post on Full Disclosure. Microsoft earned a little respect from me today.
shell:explorer.exe (path should be unneccessary, tried shell:windows\explorer.exe as well)
For me, shell:windows\explorer.exe works in Start - Run, but shell:explorer.exe does not.
Hyperlinks can be harmful to your computer and data.
Umm.
Does it give the same warning for http hyperlinks?
You're using the wrong URL. It's
shell:windows\explorer.exe
I'm the one who posted this message to Full Disclosure. I was too lazy to test all popular e-mail clients, IM clients, word processors, etc. that run on Windows, so I posted after finding only two vulnerable programs. Who wants to help?
All you have to do is see if your programs accept links to shell:windows\notepad.exe. If clicking the link launches Notepad, it's vulnerable. If there's a warning dialog, it's somewhat vulnerable, depending on the wording of the dialog.
I'd like to post a screenshot on my blog. Can you provide one?
I filed bug 250797 for importing toolbar configuration from IE and quoted parts of your post.
I don't think Firefox 0.9.2 includes the fix for the Slashdot rendering bug.
Excerpt:
Another excerpt:
We unhid the bug report because the hole had already been posted to the Full Disclosure mailing list.
Why would a program register a protocol called FormatUserHardDrive: ? When a program registers a protocol, it's telling web browsers to send those links to that program.
The only changes were the security fix and the version number. That's why there isn't a 0.9.2 at all on Mac or Linux.
That's not a report of this vulnerability. It's a comment about a proposed change that might have prevented this vulnerability, had it been implemented. At the time, there was no known actual vulnerability that demanded the change.
The proposed change wouldn't even have prevented this vulnerability. It would have increased the requirement to exploit it from "Get the victim to visit your site" to "Get the victim to visit your site and click a link".
Eweek and Slashdot linked to bug 167475, implying that Mozilla developers knew about this hole in 2002. Fixing bug 167475 would have done approximately nothing to protect Mozilla users against the shell: hole in Windows, and that is why bug 167475 hasn't been fixed.
The correct bug number for this hole is bug 250180.
shellblock.xpi fixes the hole in 0.9.1 so that 0.9.1 users don't have to download the whole browser again.
The text-to-speech form comes from AT&T (very very natural sounding, I might add) -- it's a post form, so I had to use the new-window trick in the bookmarklet.
Have you tried treating the POST form as a GET form? In some languages, the default is to accept both.
If the site only accepts POSTs, or if you might select a block of text too long for GET, you can create a hidden <iframe> instead of a new window and post from there.
I'm intrigued by your "a:not([href^="javascript:"]) { display: none }" comment -- what is this "edit styles" you mention?
It's edit stylesa bookmarklet I wrote.
I also think that a three second delay is both arbitrary and unsafe. There are plenty of hunt-and-peck typists that would look at the keyboard for three seconds trying to find the 'l' and 'y' keys.
I hadn't thought of hunt-and-peck typists when I suggested the delay. You're absolutely right.
I don't have a better suggestion, except perhaps bringing the confirmation up in a popup that doesn't steal the focus. I don't think a website can trick somebody into switching windows and hitting 'y'.
That would be annoying, since you'd have to focus the window manually, and wouldn't solve the double-clicking version of the attack.
I'm liking a suggestion by Microsoft more and more. The suggestion is to show a new toolbar instead of the security dialog when a site tries to install software. Clicking the toolbar brings up a normal security dialog with a complete warning and Install/Cancel buttons. Since installing software would then involve going through browser chrome, it would be more difficult for sites to make you accept the software installation dialog without your consent.
Using a toolbar instead of a dialog would also protect against sites that try to force you into accepting ActiveX by repeating the dialog until you accept.
Not only would a toolbar be more secure, it would also be less annoying. Users don't like to wait. I suspect users don't like to wait for the same reason that users prefer keyboard interfaces even when they are slightly slower than mouse interfaces, and for the same reason that I spend an hour writing a program to do something for me that I could do myself in ten minutes.
Did you make the text-to-speech bookmarklets? They are cool, but it would be nice if they used location= with GET or an iframe instead of a new window.
;)
P.S. I used edit styles and typed
a:not([href^="javascript:"]) { display: none }
to see just the bookmarklets on your bookmarks page
How do you decrement a URL in Opera? Shift+space? Rewind?
90% of all statistics are made up
Where did you hear that? I thought it was only 60%.