Firefox Quickies

First, Gypsy2012 writes with a highly critical security flaw involving both Firefox 2.0 and Internet Explorer, which could allow a malicious attacker to gain remote control of a user's system. It exploits the "firefoxurl://" URI handler. ... Next, reader dsinc sends word that the beta for Firefox 3 has slipped by 6 weeks. The new target date is September 18 at the earliest. The article wonders whether the final release will slip into 2008. ... Finally, reader jktowns points out new anti-phishing features in the latest nightly build of Firefox 3. One of them was added into the code base by the guy who developed the LocationBar² extension.

Comments

Demonstration

[blhack]

Demonstration

Cmd.exe
This should launch cmd.exe....

Notice that you must click that link from internet explorer, firefox will warn you that an external application is being called.

above example taken from here

Re:Demonstration

[froggero1]

Weird, I get an error message:

"Iceweasel doesn't know how to open this address, because the protocol (firefoxurl) isn't associated with any program."

and when I try to open this "ie" program:

"~ $ ie
bash: ie: command not found"

maybe there's something wrong with your operating system?

Re:Demonstration

[blhack]

Correction (something went goofey when i copy and pasted.

this ..will launch cmd.exe

If you open this in firefox (as most of you probably are usuing firefox, since this is slashdot), it warns you that something is trying to launch an external application.

once again, the above example was taken from Here

Re:Demonstration

[blhack]

DARN YOU SLASHDOT!!!!!!!!!!!!!!!

stop stripping my links! >:-O

the link in full txt is THIS:

a href = 'firefoxurl:test" -chrome "javascript:C=Components.classes;I=Components.inte rfaces;file=C[@mozilla.org/file/local;1].createIns tance(I.nsILocalFile);file.initWithPath(C:+String. fromCharCode(92)+String.fromCharCode(92)+Windows+S tring.fromCharCode(92)+String.fromCharCode(92)+Sys tem32+String.fromCharCode(92)+String.fromCharCode( 92)+cmd.exe);process=C[@mozilla.org/process/util;1 ].createInstance(I.nsIProcess);process.init(file); process.run(true%252c{}%252c0);alert(process)

Re:Demonstration

[Anonymous Coward]

Hey, 1996 called, and they want their snooty, elitist, linux user tude' back.

Re:Demonstration

[stonedcat]

Brought to you by Microsoft TimePhone98-SE (patent pending).

Re:Demonstration

[dwarfsoft]

Weird. On windows, with Firefox 2.0.0.4, and clicking on the cmd.exe launcher on the page that you linked to (and by creating my own html page) It just opens a blank tab. cmd.exe isn't launched.

Firefox 2.0.0.4 and IE6.

Doesn't even work from IE, just loads a blank tab in firefox. I guess I must be doing it wrong :D

Re:Demonstration

[BlueCollarCamel]

Firefox doesn't know how to open this address, because the protocol (firefoxurl) isn't associated with any program.

Re:Demonstration

[Anonymous Coward]

yes and we still have reasons to laugh at windows.

Re:Demonstration

[RobertM1968]

I know one similar response was modded funny, but this is truly what I got.

Firefox doesn't know how to open this address, because the protocol (firefoxurl) isn't associated with any program.

Firefox 2.0.0.4 (on eCS)

Re:Demonstration

[RobertM1968]

Same results as your previous link...

Firefox doesn't know how to open this address, because the protocol (firefoxurl) isn't associated with any program.

Same Firefox 2.0.0.4 (on eCS)

Re:Demonstration

[Frizzle Fry]

It's only supposed to work if you don't already have firefox open (and then you click the link in IE).

Re:Demonstration

[Henry V .009]

Vista UAC blocks it, interestingly enough.

Re:Demonstration

[RealGrouchy]

I take it that /. removed it from the link.

I dunno, I didn't follow the link.

- RG>

Re:Demonstration

[AuMatar]

Same result with Mozilla Seamonkey.

Re:Demonstration

[Anonymous Coward]

> hmm, so you don't have a program called "ie", so there's a problem with _his_ operating system?

I don't have this program called "W32/Blaster" either; is that bad?

Re:Demonstration

[fatphil]

Yes, yes. This is an _IE_ bug, not a firefox bug. (I think you probably knew that though, but the people who wrote the summary and added tags certainly seem ignorant of that fact.)

Firefox just does what you tell it, and 'you' in this case is an IE which doesn't escape characters that have a meaning to the shell that is going to execute the command. So it's IE pwnx0ring (is that how you spell it?) the *shell* to get it to execute firefox with arbitrary parameters. I'd be willing to bet that there's a way to get it to execute arbitrary commands, not just firefox. I don't do WinDOS, but the unix equivalent would be something like

    "; /bin/arbitrary command ; echo "

At times I wish I actually had a windows machine to try these things out on. :-|

Phil

Re:Demonstration

[rapid_snail]

It works for me. (FF 2.0.0.4, IE 6, XP SP2)

Close all FF windows
Open IE.
Go here http://www.xs-sniper.com/sniperscope/IE-Pwns-Firef ox.html/
Click on the first link (the one which says opens cmd.exe)

It immediately opened a cmd.exe window for me.

Re:Demonstration

[eat here_get gas]

worked just fine for me, although the first time it was missing all the text crap....

Re:Demonstration

[phantomflanflinger]

As with all the "Firefox security holes" I have ever seen in my entire life, Firefox enquires "would you like a virus, sir?" while IE just serves it to you on a plate.

Just my 2p. Had to say it.

Re:Demonstration

[Giorgio Maone]

Firefox users with the NoScript extension installed have been already protected both from MacManus/Larholm remote code execution and from Rios "Universal XSS" since June, the 22th, see NoScript changelog.

More in general, they're protected from chrome privilege escalation gained by opening non-chrome URLs in top-level chrome windows (Larholm's PoC) and from javascript: URLs being loaded in externally opened browser shells (Rios' PoC), no matter if attempted through the firefoxurl: handler (like in this specific case) or by other yet unknown means, thus these features are meant to stay in place even after Firefox 2.0.0.5 with its commandline-specific fix is released.

Re:Demonstration

[Nurgled]

Curiously, when I clicked your link IE loaded Firefox, and then Firefox told me that it had to load Firefox to view this URL. I clicked "Yes" and a new tab opened and it again told me that it had to load Firefox to view this URL.

Certainly didn't launch cmd.exe. What gives?

Re:Demonstration

[ericartman]

yup Vista blocks

Re:Demonstration

[Goaway]

Actually reading the announcement, this seems very much like a Firefox bug, namely in the URL handler it installs. It's IE that's just doing what you tell it, to open an URL that happens to use an external URL handler.

Re:Demonstration

[setrops]

This is a Firefox bug. They Registered their application to execute FirefoxURL and do not parse the incomming information from %1.

IE just passes the information to the registered application in the knowlege that the application would handle the request properly.

So they pass it the -chrome parameter and it executes the javascript.

C:\PROGRA~1\MOZILL~1\FIREFOX.EXE -url "%1" -requestPending

Now I wish that they would remove all DDE and OLE from IE but at this point they will not.

Re:Demonstration

[fatphil]

What do you mean 'the handler'? The string in the registry or the program refered to in that string?
If you think it's the string, then what's wrong with it, and what should be changed to fix it? (clue - nothing, anything you suggest I can provide an exploit for) Which makes you in the wrong.
If you think it's the program, then you've completely misinterpreted what the problem is (see below). Which makes you in the wrong.
If you think that it shouldn't even have added the new scheme and handler, then you've also missed the point - as demonstrated a week ago, it's nothing specific to this "firefoxurl:" scheme at all. Which also makes you in the wrong.

Conclusion: you're in the wrong.

This is a Windows OS design issue.

In particular you're wrong in your final comment, IE is *not* doing what you tell it, assuming that when a single string comes in from the user the user is telling the application to use that string as a single atomic unit. The aberrant application, in this case IE, but last week it was Safari, is ignoring common conventions about passing untrusted data to other applications. It makes no attempt to escape undesirable characters in the string. It lets the OS break that string into multiple strings. That is *only* IE's responsibility. Firefox *hasn't even seen* the original string by the time the error occurs, as it's the OS that parses that string into command line options.

Summary - for the n-th fucking time:
IE gives an insecure string to the OS, OS calls firefox with the wrong parameters. Firefox does what it's told, having no choice, as it wasn't given a chance to know what the user actually wanted.

Exactly the same as the safari bug last week.

Re:Demonstration

[trifish]

This is certainly not an IE bug, but sloppy security design in Firefox. From TFA:

Meanwhile, Kristensen of Secunia said: "A new URI handler was registered on Windows systems to allow Web sites to force launching Firefox if the 'firefoxurl://' URI was called, like ftp:// http:/// or similar would call other applications."

But because of the way the URI handler was registered by Firefox, it causes any parameter--which activates a program to perform a particular task--to be passed from Microsoft's Internet Explorer, or another application, to Firefox, when firefoxurl:// is activated.

An attacker may use "chrome" context--the interface elements of a browser that create the frame around its page displays--to inject code on a user's system that would be executed within Firefox, Kristensen said.

"Registering the URI handler must be done with care, since Windows does not have any proper way of knowing what kind of input potentially could be dangerous for an application ," said Kristensen. "For example, how should Windows know that the string 'chrome' could be dangerous for Firefox."

Re:Demonstration

[fatphil]

*Wrong*. They do parse the information in their command line arguments _exactly_ as IE passes it to them.
By the time Firefox sees the command line it is *already broken*.

IE constructs a command line that _cannot be parsed any other way_. It is IE's fault that it doesn't escape things like quote characters. No-one else can construct the string, only IE can, therefore it's only IE's responsibility. Of course, this goes all the way back to a Windows design issue whose roots are in DOS 1.0 - this is nothing to do with DDE or OLE, it's to do with process spawning and the parsing of command line arguments. Which is why Safari suffered from exactly the same flaw last week. You'd better check WinAmp and WMP, etc, as I'm sure they might be susceptible too.

Re:Demonstration

[Goaway]

What do you mean 'the handler'? The string in the registry or the program refered to in that string?
If you think it's the string, then what's wrong with it, and what should be changed to fix it? (clue - nothing, anything you suggest I can provide an exploit for) Which makes you in the wrong.

The program, of course. It should know it will be called with unsafe parameters.

It makes no attempt to escape undesirable characters in the string. It lets the OS break that string into multiple strings.

From reading up on the issue, this is incorrect. The string is not passed through the shell, so no special characters are processed, and no strings are broken up. The problem is that the program that receives the string has other options, not intended to be called through the URL handling mechanism.

Re:Demonstration

[fatphil]

But the firefoxurl: schema is a red herring.
Did you miss the gopher: demonstration last week?

It's the _same_ bug, just a different payload.

It's the application which creates the command line which is responsible for making sure it does exactly what was intended. That's IE, and Safari, and every other application which might want to have active links of these sorts. By the time Firefox sees the command line *it's already broken*.

Re:Demonstration

[fatphil]

It's *not* being called with _unsafe parameters_, it's being called with *paramters which aren't what the URL specified*.

You're right about the OS not doing the splitting of the string, that's the unix way. It's Firefox itself that splits the string int parameters, using conventions that are several decades old. However, that doesn't change where the responsibility for getting the command line correct lies. The fact that Firefox *must* interpret the string as being composed of several different parameters by following those old DOS conventions is because IE _created a sting which must be interpreted that way_.

Firefox has no choice, it's doing what IE told it.

If IE wants to pass spaces, quotes, piping, redirection, etc. in the command line, it should pass %20's etc. instead. If Firefox were to fail to interpret those in the URL, then that would be a firefox bug.

Re:Demonstration

[Goaway]

This is Windows, not Unix. There is no standardized way to parse command lines, and no standardized way to escape them. Every program parses its commandline by itself - it gets no argc and argv parameters from any shell.

This means that you can not know how to escape a command line for another app properly! Therefore, if you register a command-line URL handler, it is up to you to parse the string that the browsers passes in verbatim correctly!

This is risky, which is why you can use DDE instead of command-line options, which is safer. Firefox chose not to do this, and also does not correctly take into account that the string passed through the command line is by design and convention entirely unescaped.

Re:Demonstration

[The Spoonman]

maybe there's something wrong with your operating system?

Nope, there's something wrong with Firefox. IE (and it works with Safari Beta 3, as well) is just doing what it's supposed to do: handing specific URLS off to its handler. If you have FTP URLs open in a third-party app which is then exploited, is the problem STILL with the browser that launched the handler? Of course not. Worse, this exploit only works when the URL is passed to Firefox, not when it handles the URL directly, which means Firefox is only validating the URL correctly when it handles it directly. You can blame the OS all you like, but poor coding from the Firefox team is still poor coding from the Firefox team.

Re:Demonstration

[fatphil]

OK, I accept that the finger of blame could be pointed at Firefox for simply having too many features available on the command line. However, there must have been some (poorly thought out) reason why that was a desirable feature. Like executing javascript in e-mails... . Justify the removal of that feature to the satisfaction of the Firefox developers, and you'll have made your point. I'd even support you in this aim. Creaping featuritis is one of the biggest enemies of security.

Re:Demonstration

[Goaway]

The fact that Firefox *must* interpret the string as being composed of several different parameters by following those old DOS conventions is because IE _created a sting which must be interpreted that way_.

It did no such thing, and there is no requirement to follow any old DOS conventions. It created a string as dictated by the registry entry and the API design. Firefox did not understand how the API works, and misinterpreted the resulting string.

If IE wants to pass spaces, quotes, piping, redirection, etc. in the command line

Piping and redirection are handled by the shell, and totally irrelevant to this argument. If Firefox is unable to handle spaces and quotes in the URL, it should be using DDE, which does not have these problems. They chose to use the command line, but they disregarded the fact that the options are by OS design NOT escaped in any way.

Re:Demonstration

[Goaway]

There is no requirement to use the main executable as the URL handler. Proper design would use an auxillary executable as the URL handler, or would use DDE instead, or would have a special-case command-line parser when called with some kind of "-urlHandler" option that would disable quoting and spaces after that point.

Re:Demonstration

[fatphil]

What you say disagrees with what's in the analysis by the guy who found the bug:

http://larholm.com/2007/06/12/safari-for-windows-0 day-exploit-in-2-hours/

He thinks that there's command line processing taking place. I have no ability to verify that,
I have no access to any windows machines.

Can you perform his "Fire up procexp, launch safari and watch the output." test and forward the pertinant output here?
And with IE rather than Safari?

Re:Demonstration

[fatphil]

"There is no standardized way to parse command lines, and no standardized way to escape them."

Microsoft seem to disagree with you:
http://msdn2.microsoft.com/en-us/library/a1y7w461( VS.80).aspx

Of course, their system is braindead, but it *is* standardised.

Re:Demonstration

[Goaway]

Read a little closer:

Microsoft C startup code uses the following rules when interpreting arguments given on the operating system command line:

This is what their particular startup code does. It's just one particular implementation, not any kind of standard.

Re:Demonstration

[Goaway]

Firefox does not chose how to parse the command line, that happens before main() is ever called. Firefox _does_ get argc and argv. So yet again, it's not Firefox's fault.

Yes, it does. It choses to accept what gcc's startup code feeds it. That's a choice. It could, and would have to, implement its own argument parsing to work properly as an URL handler.

More sanely, it should use an external executable as the URL handler, or even better, use DDE and not the command line.

PS:

If that's the case, then windows is broken beyond repair.

Not really any more broken than Unix. Unix enforces some minimal command line parsing, but not enough for programs to be in any way consistent, while it does too much processing to implement certain other kinds of argument parsing, such as AmigaOS-style ReadArgs().

Re:Demonstration

[Goaway]

Read that again. He's showing that command line processing of the pipe character does not take place, because it shows up verbatim in the arguments of the process launched. If the shell was processing the pipes, the command line would stop just before the pipe, and there would be a second process with the rest in it.

He then proceeds to find a real exploit by using unintended consequences of normal Firefox options, specifically, the -chrome option. So, once again, the bug is that the -chrome option of firefox allows you to execute commands, combined with the fact that you can inject a -chrome option into the command line parser.

Re:Demonstration

[mdew]

hmm I wonder if you could use adblock to block "firefoxurl://" it would prevent this issue?

Re:Demonstration

[Giorgio Maone]

No, adoblocking "firefoxrurl:" won't work because Firefox doesn't receive a firefoxurl:, but a javascript: URL (The "firefoxurl:" part is stripped out by IE or whatever the calling application is).

As I said, NoScript it the extension providing specific protection against this class of attacks.

Re:Demonstration

[stonecypher]

This is, of course, ridiculous. There is no point at which the way in which a protocol handler should disable IE's security path; it's worth noting that the Yahoo Instant Messenger protocol handler ym:// has a very similar flaw. This isn't the registrant's fault. This is the fault of IE allowing any protocol handler to do whatever it likes. Whereas it's openly silly that Firefox should have created such a handler, to suppose that IE is not responsible for security checking its interpretation of the behavior of other applications is what caused most of IE's security problems in the first place.

If the problem was Firefox, then this would work in Opera too.

Re:Demonstration

[stonecypher]

since June, the 22th

That's funny, I thought it was on the 21nd.

Re:Demonstration

[trifish]

So, um, once again, how exactly is Internet Explorer supposed to know that "chrome" is an insecure keyword that can execute scripts in SOME program out there?

Re:Demonstration

[trifish]

So, maybe you know the answer... Let's see... How exactly is Internet Explorer supposed to know that "chrome" is an insecure keyword that can execute scripts in SOME program out there?

Re:Demonstration

[Giorgio Maone]

That's funny, I thought it was on the 21nd.

The 1nd version of this protection was released on the 20rd, and the 22th one was actually the 3st, as testified by the changelog ;)

Re:Demonstration

[fatphil]

If the development tools provided by the OS vendor themself do not provide a de facto standard, I don't know what does.

Re:Demonstration

[fatphil]

"It choses to accept what gcc's startup code feeds it."

I'm beginning to wonder if _anything_ you say can be taken as true now.

http://developer.mozilla.org/en/docs/Windows_Build _Prerequisites

Firefox builds with Visual Studio. So it accepts what MSVC's start-up code feeds it.

And no, it _should not_ change its command line parsing to make it different from the standard.

Some other program gave it a broken command line. End of story.

Re:Demonstration

[fatphil]

OK, I misread. His punctuation was misleading.

The question now becomes whether the -chrome option being able to contain javascript is a bug or a feature.
It's the bloatware developers who think it's a feature, and you who thinks it's a bug. I'll bow out.

And stop calling it "injecting code into the command line parser", it's not injecting anything, it's just a command line. It accepts the command line, it parses the command line, including the -chrome switch, as it's just a command line. A command line created by a buggy piece of software that let you inject undesirable arguments into what it creates. See for example his comments on Safari:
"""
With a simple link you cannot pass along arbitrary characters to the command line which is later executed and most attempts at doing so will simply be URL escape, such that myprotocol://someserver.com/some"[SPACE]argument is turned into

        "C:\Program Files\My Application\myprotocol.exe" "someserver.com/some"%20argument
"""

That's what Safari should be doing with iframes, and IE should be doing too.

Re:Demonstration

[KnightMB]

Didn't work for me. First it gives you a warning, which for me would be a red flag, but if you click to launch anyway, nothing happens. So what version of Firefox did they mean? I'm using 2.0.0.4 on Windows XP and as far as I can tell, this exploit is a non-exploit.

Re:Demonstration

[fatphil]

It's not supposed to know. It shouldn't know. That would be dreadful coupling.

It's supposed to ensure that the command line it asks the OS to execute is encoded such that the string it thinks is the URL is what will be parsed by firefox as the URL. Given that Firefox is written in C and built using MS's visual studio, then it should use the rules that MS provide (I included a link to MSDN in one of my other posts) regarding how the command line will be parsed. That means that it should escape all characters which have important meanings in command line parsing. That way the URL will be interpreted by firefox as a single string with dodgy characters in it which is then subsequently rejected, rather than as a sequence of different strings, one of which is interpreted as the URL and others as other switches.

Re:Demonstration

[trifish]

Internet Explorer is making a user-initiated request and passing it to Firefox. Firefox doesn't sanitize input. Go figure.

Re:Demonstration

[stonecypher]

This isn't complicated. "Do I know what it is? No? Then it can't run scripts."

Re:Demonstration

[fatphil]

IE doesn't sanitise the input. IE's the one building the command line.

Re:Demonstration

[edxwelch]

but wouldn't noscript cause other problems?
About 50% of all the websites I visit need javascript to function properly.

Re:Demonstration

[Goaway]

Whether or not it does is largely irrelevant, as IE and Safari both simply call into the OS APIs for URL handlers, which behave in a certain fashion by design. The developers of Firefox failed to take that behaviour into account.

The fact that that behaviour is somewhat unhelpful is no excuse for not accommodating for it.

Re:Demonstration

[Goaway]

It's the bloatware developers who think it's a feature, and you who thinks it's a bug. I'll bow out.

I do not. I think it's a bug to use the main Firefox executable as the target for the URL handler, given that its command-line parsing is not safe to be used as such.

Re:Demonstration

[Giorgio Maone]

That's the difference between NoScript's script management and the ordinary enable/disable JavaScript controls.

NoScript lets you allow JavaScript on the sites you trust (and those only), either temporarily or permanently, with a click.

Furthermore, it gives you the same trust-based control over other potentially dangerous and exploitable technologies, like Java or Flash, and protects your trusted sites against XSS attacks.

Re:Demonstration

[edxwelch]

"NoScript lets you allow JavaScript on the sites you trust "
That only works if you visit the same web sites each day. Really what happens is you visit several new websites each day and when they don't work you spend ages trying to figure out why it doesn't work before you remember that you need to specifiaclly unblock the site.

Re:Demonstration

[fatphil]

I think you can already guess that I disagree.
He who builds the command line is responsible for what it does.

Full stop.

Re:Demonstration

[fatphil]

I've said this before, but you seem clue-resistant:

Firefox does not parse its arguments. The MS runtime startup code parses the arguments according to published MS standards.

So if the executable called 'firefox.exe' is to blame, it's becuase of this entity labelled 'MS'.

Re:Demonstration

[dwarfsoft]

OK, seems like your the smartest guy here.

1. I closed all open applications
2. I opened IE
3. I went to the site
4. I clicked on the link
5. I got an error from IE (about trying to open the link)
6. Firefox opened up a window
7. Firefox asked me to launch app
8. Firefox shows a blank tab
9. I see no cmd.exe running

So I guess I still must be doing it wrong. I guess you must enjoy trolling and assuming everybody else is as incompetent as you.

Re:Demonstration

[z-vet]

"Iceweasel doesn't know how to open this address, because the protocol (firefoxurl) isn't associated with any program." I think something broken there in my browser.

Re:Demonstration

[fatphil]

Well I wasn't the only one who pointed out the fact that what you reported indicated that you hadn't followed the instructions. The fact that you come back with a different report of what you did implies that either you admit you got it wrong first time, or that you reported it incorrectly the first time. You made a mistake. Get over it. Move on.

Anyway, quite what happens on that lame-arse OS, I have no idea, and I couldn't give a shit.
Doesn't work for you? Whoopie doo, you're safe for another week.

Re:Demonstration

[Goaway]

That's about as relevant as saying that it's not Firefox that's parsing them, it's the CPU.

Fact is, they made a choice to go with the MS parser, which is not appropriate for this task. It's a subtle bug, but it's a bug nonetheless, and it's up to them to fix it. Furthermore, even if they do use the MS parser, they could still avoid this bug - the actual problem is that they are expecting the quotes they put into the registry string to protect them from spaces. This is not the case. They should be expecting the argument to come in across several different argv[] entries.

It would certainly be less of a hassle if the string was escaped in some standardized way, but those are not the rules of the game. It isn't, and you compensate for that in other ways, or you do not use the command line at all, which is definitely the safest option.

Re:Demonstration

[Goaway]

And who "builds" the command line? The OS which just runs sprintf(template,url), or the application which supplies the template?

I'd say it's the responsibility of the application to supply a safe template to the OS.

Re:Demonstration

[Goaway]

I don't think you're understanding the problem. It has nothing to do with "running scripts". And your solution is basically to remove external URL handlers completely. Now, it might be argued that that would be safest, but it certainly does not make for a very useful system.

The actual problem is that the Firefox main executable has command-line options which have an unintended side effect of being able to run external programs. And Firefox installs an unsafe command-line-based URL handler which allows web pages to pass arbitary options to the Firefox executable.

Re:Demonstration

[fatphil]

"the actual problem is that they are expecting the quotes they put into the registry string to protect them from spaces. This is not the case."

Wrong. It protects them from spaces. It doesn't protect them from quote characters.

MS designed the command line. MS designed it broken. MS designed the way that the registry entry is used to construct a command line. MS designed that broken too. IE uses these interfaces in a broken way. Firefox is a victim of all of these things.

You are right that simply avoiding these broken interfaces is the best option. Simply avoiding anything designed by microsoft is the better option.

Re:Demonstration

[fatphil]

Provide a safe template please.

I bet you it takes me less than 20 seconds to come up with a string which will break your template.

Wait a second, I think I already asked you for one, and you didn't supply one... hmmm.... suspicious...

You may alternatively respond "there is no safe template, MS designed the interface in such a way, namely broken, that no security could be guaranteed unless *all* clients of the interface take responsibility for sanitising the string they pass".

Re:Demonstration

[Goaway]

Here:

firefox-urlhandler.exe %s

Re:Demonstration

[trifish]

IE doesn't sanitise the input. IE's the one building the command line.

God, read TFA. Neither Windows nor IE can know that "chrome" is an insecure word that needs to be taken care of in a special manner. It's Firefox who interprets and executes the "chrome" stuff. Read TFA.

Re:Demonstration

[stonecypher]

I don't think you're understanding the problem. It has nothing to do with "running scripts". And your solution is basically to remove external URL handlers completely.

Er, no, it most certainly is not; I write several applications which are critcially dependant on HKLU protocol handlers. At no point did I advocate the removal of the tool, nor in fact did I advocate anything similar to what you describe. That you should suggest I don't understand the problem, then go on to be this confused about the nature of my solution, is simply remarkable.

The actual problem is that the Firefox main executable has command-line options which have an unintended side effect of being able to run external programs.

I'll say it again. If this was really the problem, then IE would not be the only gateway to this bug; you would be able to trigger this from Opera, Safari/Windows, from various instant messengers and so forth. That said, you cannot. Why? Because all of the programs named except IE do the exact same very simple thing that prevents the problem from occurring. It doesn't require "removing external url handlers completely;" it just requires handling them sensibly.

So, let's try this again. Maybe you'll listen this time. "Do I know what protocol that is? No? Then don't let it run applications." That isn't at all the same thing as removing protocol handlers entirely. Protocol handlers can explicitly name applications and then IE knows what they are; this requires user interaction, which you know if you've ever installed Yahoo Messenger. There has been a system in place for this since Windows 98, and everybody uses it but IE.

Perhaps you should spend a little more time becoming familiar with how Windows works before telling other people that they don't understand the problem. I wrote an article about this problem and submitted it to CERT and SlashDot almost ten years ago.

This is old news. Please give more credit to your fellow slashdotter; they're not as stupid as you seem to believe.

And Firefox installs an unsafe command-line-based URL handler

There is no such thing. That's why there's only one path to exploit this handler - through IE. The reason that nothing else can trigger this flaw is that the flaw is not in the URL handler, but rather in IE's interpretation thereof.

Re:Demonstration

[Goaway]

This is old news. Please give more credit to your fellow slashdotter; they're not as stupid as you seem to believe.

My apologies, but when you say "scripts" when you mean "applications", it's easy to make quick assumptions. That said, I still don't quite see what you're getting at here:

"Do I know what protocol that is? No? Then don't let it run applications." That isn't at all the same thing as removing protocol handlers entirely. Protocol handlers can explicitly name applications and then IE knows what they are; this requires user interaction, which you know if you've ever installed Yahoo Messenger.

By "I", do you mean the user? And do you mean that the browser should ask you if you want to launch an external application?

That helps against automatic attacks, but it does not seem to protect against attacks of the variety "Click this button to open our cool app in Firefox!" / click / "Do you want to open Firefox?"

The problem is that you can inject commands to launch arbitary apps in the Firefox command line, not that you can launch Firefox.

Re:Demonstration

[fatphil]

So you're introducing another executable into the chain? No wonder windows requires great gobs of RAM and dual core processors. Spawning ain't cheap on windows. OK, have it your way, have a separate application whose sole job is to sanitise the URL before passing it safely to the real firefox, if you like. Shame it's only useful for one single role, as it can't be given any parameters to change its behaviour. I wonder how many of these helper applications you'd need for different methods of invocation. You seem to be forgetting that the command line switches were put into Firefox for a reason.

So you *really* don't think it would just be simpler for IE to just escape characters that mean something to the command line parser?

Side impact bars are not the solution to drunk driving.

Re:Demonstration

[fatphil]

No, you read the description of the exploit. The original Safari one.

There is no need for any IE to have any knowledge of command line switches in order to sanitise the command line.

The problem is turning what should be one command line argument, a URL, into more than one command line argument, including some harmful switches. That is done by escaping from the quotes. Which is done by permitting quote symbols (and then spaces) onto the command line, rather than escaping them.

It really is that simple to solve. This is done in a million other places quite happily. IE forgetting to do it here is sloppy and, in simple terms, a bug.

Re:Demonstration

[cbhacking]

I didn't get a single UAC prompt in this, though it didn't work either so it might be more accurate to say it doesn't work if you aren't running as Administrator. IE7 also hits you with a big warning message about a website trying to open a program on your computer...

Re:Demonstration

[dwarfsoft]

Funny, working for the Government I don't get to choose my OS, but at least I can choose my Browser.

Re:Demonstration

[trifish]

You are wrong. Internet Explorer escapes URLs correctly. There is no problem with https:/// ftps:// news:// ldap:// and other protocol handlers. It is only the UNKNOWN (to Windows and MS) firefoxurl:// protocol that neither Windows nor MS know HOW TO ESCAPE CORRECTLY! How can they know which URLs are acceptable? How can they know that it shall conform to e.g. HTTP 1.0 spec? It doesn't know which characters to escape or strip and not break the thing. Read what the security researcher said.

Finally

[suv4x4]

Finally!

First, Gypsy2012 writes with a highly critical security flaw involving both Firefox 2.0 and Internet Explorer

Earlier when Microsoft's IE team flew over to Mozilla HQ to ask them about their RSS icon, I knew it that's the beginning of a wonderful partnership.

What OS

[jshriverWVU]

Every once in a while I see posts about Firefox or IE or whatever with a security flaw that allow remote access or malware/virii to be installed. But they never say what System it affects. Granted for IE it's pretty simple, but once you add firefox into the equation you have to wonder does this effect Linux too? Even so if the bug is in the linux firefox version, does it really matter at a system level, as many sites that might use this bug are going to be geared toward Windows users.

Granted if it's a bug it needs fixed regardless, but I would be more shocked if it said "allows a person to gain remote access on ALL systems running said software".

Re:What OS

[blhack]

well...if you read the article you would find that this bug effects Internet Explorer users, not firefox users. The exploit has firefox as a dependency, but is actually called from IE.

Re:What OS

[netdur]

Windows only http://blog.mozilla.com/security/2007/07/10/securi ty-issue-in-url-protocol-handling-on-windows/

Re:What OS

[suv4x4]

But they never say what System it affects. Granted for IE it's pretty simple

Is it. Most exploits that would work on XP wouldn't work on Vista in protected mode.

Re:What OS

[Anonymous Coward]

"virii" is not a word. It's viruses.

http://en.wikipedia.org/wiki/Virii

Re:What OS

[jshriverWVU]

Perhaps this is a term difference, but hasn't all versions of Windows from 95 up been running in protected mode? Otherwise how do they get access to larger linear memory mapping versus segmented chunks like the DOS days.

Re:What OS

[GIL_Dude]

Internet Explorer protected mode in Vista puts IE running at the "low integrity" level meaning it can only access a very limited number of folders (for example the temporary internet files folder). At the low integrity level it is very difficult to actual exploit a machine as you don't have the rights to access much.

Re:What OS

[stevey]

You're correct. Protected mode means something different in this context.

Nowhere near as much fun as handling triple faults in your assembly code!

Re:What OS

[Red Flayer]

The exploit has firefox as a dependency, but is actually called from IE.

So what you're saying is that if you have IE installed on your computer[1], it is a security risk to install Firefox?

Are we *sure* this is a bug, not a "feature"?

Right now, somewhere in Remdond, someone is planning a press release...

[1] By extension, if you are one of the 97.46% of desktop users worldwide with Windows installed.

Re:What OS

[Mundocani]

I'm running Vista and trying the link in IE just causes Firefox to launch, at which point Firefox puts up the security warning about external applications. Guess it's only XP and earlier that can trigger an unprompted launch.

Re:What OS

[StupiderThanYou]

well...if you read the article ... If you who the what now?

Re:What OS

[suv4x4]

Perhaps this is a term difference, but hasn't all versions of Windows from 95 up been running in protected mode? Otherwise how do they get access to larger linear memory mapping versus segmented chunks like the DOS days.

It's not related to the memory protected mode really, now that I think of it, not very good choice of words on MS part, as it (obviously) could cause confusion.

It's a "low permissions" mode.

Re:What OS

[Khuffie]

This has nothing to do with IE and everything to do with Firefox on windows. Firefox itself registers the "firefoxurl" URI in the Windows Registry, meaning that any application that renders HTML (ie, such as Opera) will popup FIrefox when that handler is invoked.

Re:What OS

[bdwebb]

The problem is that Vista won't run on Vista in protected mode.

Re:What OS

[fatphil]

You obviously don't understand how shells work. The bug is between IE and the shell. IE passes an untrusted string to the shell, the shell creates a command line to execute, and the shell executes it. There is _absolutely_nothing_ that firefox could do to prevent this exploit, apart from not registering such a scheme handler at all. All such registered scheme handlers are equally vulnerable from this IE bug, not just firefox.

Opera is perfectly capable of escaping characters that have meaning to the shell before passing the string to the shell to build the command line. Whether it does so is another matter. I don't have a windows machine on which to try. If it doesn't, then it's an Opera bug as well as an IE bug.

Re:What OS

[mr3038]

You obviously don't understand how shells work. The bug is between IE and the shell. IE passes an untrusted string to the shell, the shell creates a command line to execute, and the shell executes it. There is _absolutely_nothing_ that firefox could do to prevent this exploit, apart from not registering such a scheme handler at all.

If I've understood correctly, the problem is not (this time) that IE skips the encoding of shell parameters but that the firefoxurl scheme handler is too powerful. MS used once to say that all scheme handlers should be made safe to use in the internet. So if one can put anything in firefoxurl scheme handler and it will be executed by firefox as is, the problem is in the firefox. It's the scheme handler that should make sure that it handles the scheme safely.

But then again, if the current specification is that scheme handlers are not supposed to be internet safe (that is, visiting any URL with any scheme should not be considered safe), then the problem is in IE. It should only enable schemes that it considers safe.

Re:What OS

[Vo1t]

Is it. Most exploits that would work on XP wouldn't work on Vista in protected mode.

Is it. Most exploits that would work on XP wouldn't work on Vista in turned off mode.

Fixed that for ya.

Re:What OS

[fatphil]

What do you mean by 'too powerful'? It's exactly as powerful as pretty much any other scheme handler. And amazingly, other scheme handlers are vulnerable too. See the exactly equivalenty Safari exploit from a week back. He used "gopher:" as the scheme, not "firefoxurl:". The error lies in the source browser to OS (i.e. the thing that actually spawns a process) interface. Windows specifies handler behaviour in terms of building a single string which is later parsed into individual arguments. Because of that, what should be a single parameter can break itself into many parameters, or even multiple commands separated by command separators or piping, or whatever.

Re:What OS

[kauttapiste]

Is it. Most exploits that would work on XP wouldn't work on Vista in protected mode.

Yeah, since that would require software actually to run on Vista. ;-)

Re:What OS

[StormReaver]

"Internet Explorer protected mode in Vista...don't have the rights to access much."

Does Internet Explorer come this way by default? If not, then it's of no use to 99+% of Vista victims...err...users since they won't change the defaults.

Re:What OS

[mattspammail]

Naming convention idea: follow Symantec's lead: http://www.symantec.com/avcenter/vnameinfo.html

Ex: W32.BAT.FirefoxAndIEriskThisAffectsYouAndItsReally BigItCanEvenSpawnBatchFilesOMG.dr.A

Re:What OS

[SEMW]

Turn UAC back on. Protected mode is part of UAC privilege level seperation, and won't work if you have UAC turned off.

Re:What OS

[SEMW]

Does Internet Explorer come this way by default? If not, then it's of no use to 99+% of Vista victims...err...users since they won't change the defaults. Yes, it is turned on by default. The worry is that people will turn it *off*: protected mode is part of UAC...

Re:What OS

[Tim C]

But if you are using IE to surf for pr0n, serialz and spyware, why would you have Firefox installed?

Because someone else who uses the machine installed it? Because you heard about it, installed it, but didn't like it?

Re:What OS

[Mundocani]

Thanks - I do in fact run with UAC turned off so I'll try it with it turned on instead. As a side note, I don't hate UAC and like the *idea* of it, but not the implementation that Microsoft chose. Too annoying and they need to refine it into something far less obtrusive. Ironic that leaving it off prevents this one particular security problem though.

Re:What OS

[SEMW]

Ironic that leaving it off prevents this one particular security problem though. What do you mean? The only thing leaving off would do is reduce by one the number of prompts you'd have to go through to just the Firefox one. What problem is prevented?

(For me, the Firefox warning about external applications pops up after the cmd window does. Not much use...! But it does that whether I have UAC on or off; the only difference the two being whether IE pops-up a warning. No reason for Firefox to behave any different).

Re:Ok....

[bhtooefr]

There are some sites that don't work with Firefox.

Hell, I've got Firefox on my WIndows system (but Opera is my main browser,) and I usually end up using IE for some sites.

Doesn't it require IE first?

[khasim]

From TFA:

The trouble begins when browsing a malicious site while using IE and it registers a "firefoxurl://" URI (uniform resource identifier) handler, which allows the browser to interact with specific resources on the Web.

Sorry, can't try it right now as I'm on Ubuntu (Feisty Fawn). But I'll look into it tomorrow when I get to work.

Re:Ok....

[jshriverWVU]

Yes QA testers. Or people who don't really pay attention and use Firefox normally. But when an app or email says "click this link" and IE is the default browser if pops up.

So do I. For ones I absolutely have to trust.

[khasim]

Normally, I'm surfing with Firefox and NoScript and AdBlock and ....

It keeps me safe.

If a site doesn't work with that, then fuck them. I only need IE for some work related sites that have stupid ActiveX controls.

Re:Ok....

[deepestblue]

In fact, this is my primary usage model. I use IE 7.0 for most general browsing since it's "good enough" and it's actually more reliable than FF (crashes less often). But Firefox tabs are just way faster (actually, it's the other way around - IE tabs are horrendously slow). So for my morning-news scenario, I launch my RSS aggregator through FF and middle-click away.

I saw a main reason why forms fail

[ericrost]

I actually figured out the issue on a intranet site at work. When IE (which has become the default expected behavior) passes a field into a url, if its blank it inserts a null character, when firefox does it, it omits the field. This borks code that doesn't expect the field to be omitted.

Re:I saw a main reason why forms fail

[ericrost]

That's nice and all. I agree we should have standards, I was pointing out that its something IE (in many cases the default behavior expected) does differently than firefox that causes code to screw up. I use Firefox on Linux. I just understand that people don't expect me to.

Re: Firefox crashes

[bunratty]

Firefox crashes for you? Read the MozillaZine Knowledge Base article about Firefox crashes and you can probably fix your problem.

Doesn't work with Firefox 1.5.x.x

[Fluffy Bunnies]

In case anyone was wondering. Seems like skipping version 2 was a good choice after all.

Re:Doesn't work with Firefox 1.5.x.x

[risk one]

So you're saying that running an unsupported version is better than risking this minor exploit which only affects ie users that have firefox installed (so pretty much noone) and will probably be fixed in a couple of days by Mozilla, even if it isn't their bug. Yeah, sticking with 1.5 is the way to go.

Re:Doesn't work with Firefox 1.5.x.x

[Fluffy Bunnies]

1.5 was supported until something like a month ago. I don't see going unsupported for the few months until 3 is released as that big of a risk, especially as I haven't heard of a single major security risk that upgrading to 2 would shield me from.

Free Diease. Now pay for the Cure.

[BillGatesLoveChild]

Firefox hasn't released a fix for this, and there is no mention of it on their web site.

Now this blows:

http://secunia.com/advisories/25984/
> Solution:
> Do not browse untrusted sites.
> Disable the "Firefox URL" URI handler.

The first is impractical. The second begs the question, "Sure, How?" Read on:

> Extended Solution:
> The "Extended Solution" section is available for Secunia customers only.
> Request a trial and get access to the Secunia Customer Area and Extended Secunia advisories.

So these guys are publishing zero day security flaws, then making you reach for your credit card. Very grubby.

The CNET article doesn't tell you what the fix is either. Google has nothing. Anyone?

Re:Free Diease. Now pay for the Cure.

[David_W]

Disable the "Firefox URL" URI handler.

[This] begs the question, "Sure, How?"

URI handlers are stored under HKCR in the registry. If you rename or remove HKCR\FirefoxURL it should disable the handler. Note that I have no idea what other impact doing that would have.

Re:Free Diease. Now pay for the Cure.

[Fluffy Bunnies]

Errr, manually remove the entry from Windows registry seems like the obvious way of doing it. What exactly is the problem here? Uninstalling and switching to portable Firefox 2 or Firefox 1.5 would also work...

Here's how...

[mario_grgic]

Open Windows Exporer (not Internet Explorer) and from the Tools menu select "Folder Options" menu. On the dialog that appears select the "File Types" tab.

Now in the list of registered file types find the one that says:

"(NONE)" for extension and "Firefox URL" for file type

Select it and click on delete button to delete it.
Click on "OK" to close the "Folder Options" dialog.

Re:Here's how...

[BillGatesLoveChild]

Thanks very much! Was a little different when I got there, but this seemed to do it: The [Delete] button was greyed out for some reason my PC(!?), so selected it anyway, click [Advanced], [Remove], Sure? [yes]. The entry stays there, but now typeing firefoxurl://slashdot.org in IE says "No Program is associated with this".

Re:Here's how...

[Tolkien]

Wait, what?

You mean I need to do something thoroughly counter-intuitive to reproduce this bug? Wow.

The first security hole patched by human laziness.

Re:Here's how...

[Tolkien]

Never mind, spoke too quickly and misunderstood.

IE problem, but also Firefox problem.

[The MAZZTer]

Firefox will warn you if a program tries to use other protocols. It will allow you to suppress the warning, however, which can cause the same problem as IE, but at least you can't say you weren't warned. So from this POV, it is IE's problem moreso than Firefox's, especially when it's considered that the URLs can't do anything from WITHIN Firefox, and that (I haven't checked this, just heard it somewhere) the protocol was requested by MS for some Vista compatibility thing or some such nonsense. Not sure if there's anything to that.

However, on the flip side, anyone who implements a protocol needs to be aware any web page can invoke the protocol at will, without the consent of the user (well, thanks to IE's "standards"). This results in being able to do things like this. This webpage redirects the browser to steam://open/main, which will open the main Steam window. The user never sees the actual url. This could work with the firefoxurl protocol as well. Here are some other things that can be done, some of the uglier ones have confirmation screens I believe, but launching a game or connecting to a server does not. Note the first one which promises that it can redirect command line arguments, just like firefoxurl... however I cannot get that to work (I tried -shutdown and it just focused the main window like my current sample does). Also note the hackish steam://openurl/, which is designed to allow Steam's built-in IE browser to invoke the computer's default browser. Theoretically this could be used to bypass a popup blocker.

Of course it would appear that Steam at least can't run arbitrary programs and is limited to it's own folder in terms of effects (I could force you to join my UBER LAME COUNTER STRIKE SERVER but that's about it).

I think both Microsoft and Mozilla need to take steps to fix this problem. Microsoft needs to improve external protocol handling to at least what Firefox does (Firefox could even secure its own handling more, but that might detract too much from the flexibility. Not that that's stopped anybody before). Mozilla should remove this silly firefoxurl bit. I can't think of any legitimate reason for it (anyone have any clue?).

As for Valve with Steam... steam://openurl/ is a bit much I think. It's expected for users who don't know what MSHTML or ActiveX are to think it's a bug that external windows open in IE, but us devs know that, internally, IE is just spawning a new window for a page. Since when were you browsing the web in IE and click on a link and it popped open in Firefox? I wouldn't want that to happen if I preferred IE! (Yeah... firefoxurl is definitely useless.) I mean, can't Valve say that because Steam uses Internet Explorer internally for the Store, all launched webpages will appear in Internet Explorer and there's no way around it? Eh probably not. The technically inclined probably think everything is great now and wouldn't care if anyone told them Valve used a hackish and possibly unsafe solution.

Although at the least they could use a whitelist for urls to use for openurl... IE steampowered.com and whatever other sites they link to... although considering the number of third party games being added it could be a largish list. :(

Perhaps steam could kick the steam:// thing entirely, but the only alternative I can think of is an Internet Explorer BHO (ick, not worth the trouble IMO), unless they can do something fancy with javascript or java or flash or something.

Here's a bonus for reading all this: You can see what available protocols Windows / Internet Explorer can use (Firefox too, although it has its own extras like about: and data:) by checking HKEY_CLASSES_ROOT in regedit. Search for Values with the exact name of "URL Protocol" and the keys you find (or maybe it's in the default value?) are the protocol names. With a look it can be easy to figure out how

Re:IE problem, but also Firefox problem.

[ikkonoishi]

If you have mIRC you probally also have IRC://.

Like so.

Re:IE problem, but also Firefox problem.

[BZ]

> I can't think of any legitimate reason for it

It's a protocol scheme Windows makes up based on the registry keys Firefox has to set to get things like http: associated with it.

To be more precise, what Firefox does is:

    register HKLM/SOFTWARE/Classes/FirefoxURL with a shell/open/command
    subkey and then set the values of ftp, gopher, http, and https to
    FirefoxURL under HKLM/SOFTWARE/Clients/StartMenuInternet/FIREFOX.EX E/Capabilities/URLAssociations

This causes Windows to send "firefoxurl:" URLs to Firefox.

Not much to remove here on Mozilla's end.

Re:IE problem, but also Firefox problem.

[Cheesey]

his webpage redirects the browser to steam://open/main, which will open the main Steam window. The user never sees the actual url... some of the uglier ones have confirmation screens I believe, but launching a game or connecting to a server does not.

It really bothers me that a Steam game server (e.g. for CS:S) can force your computer to open any webpage as soon as it connects. This is used by some CS:S admins to make welcome screens with persistent scoreboards. But an Internet Explorer widget is used, and this seems a very obvious vector for exploits - it is also annoying. Do you know of any way of turning it off?

Requires firefox to exploit from IE

[Heathhunnicutt-enwik]

The fact is that the URI handler firefoxurl:// is installed by.... Firefox.

In other words, IE is redirecting to the firefoxurl DLL or EXE installed by Firefox, and that is the code which is executing user input without warning.

To me it seems disingenuous to blame the IE implementation for handing control to the Firefox protocol handler, which is treated like a shell plug-in. It seems the responsibility to prompt the user should rest on the protocol handler. Otherwise, IE would be expected to prompt on the execution of any protocol handler that was unknown at the time that IE shipped, or some such "prompting heuristic." This would be inconvenient and also subjected to ridicule on /.

AH!

[biggerboy]

I knew there was a reason to use Safari :-)

Re:AH!

[fatphil]

You fucking idiot.

http://larholm.com/2007/06/12/safari-for-windows-0 day-exploit-in-2-hours/

Same bug.

Re:Kdawson...

[Farmer Tim]

That's the new text format randomizer , w'hic'h optionall'y add's inap'propriate a'p'o's' t'r'o'p'h'i'es .

It was added a couple of months ago to settle a bet whether Slashdot's editors are better than a random number generator (as yet no winner has been declared).

Re:this story sucks

[Anonymous Coward]

Ruin JavaScript? I'm afraid it's far too late for that.

What earthly use is "firefoxurl" anyway?!

[_xeno_]

After reading about "firefoxurl" and what it does, I only have one simple question: what on earth were they thinking when they implemented it? What's it supposed to be useful for?

As far as I can tell, the only use it could possibly have is creating desktop URLs that always open in Firefox, however there's no reason why they would have to create a URL handler to do that. Otherwise, it's completely worthless and, as discovered, a security risk, to boot.

For added fun, attempting to use a "firefoxurl" URL while Firefox is already running creates an infinite loop. (It just keeps on asking you to allow an "external application" to launch. It doesn't even seem to actually work. I get the same results when launching it directly from IE through the address bar.)

Why was this implemented? What was it supposed to do?

And, for bonus points, is it possible to write a firefoxurl that, when opened in IE, would unregister the firefoxurl handler?

Re:What earthly use is "firefoxurl" anyway?!

[schweini]

Without actually looking it up, I'd guess this feature is useful for example if you develop XUL-based applications and the like. You could then link to the XUL application on your website, and IE (if you're using it to browse the site) would open the application in FF.

Re:What earthly use is "firefoxurl" anyway?!

[_xeno_]

Except that's still retarded, since it's by definition a remotely executable code exploit. URLs don't have to be loaded by users, and in some cases, can even be loaded without any user interaction. (<meta http-equiv="Refresh"> comes to mind, although I haven't gotten the exploit to work on my system yet).

XUL applications have access to basically everything on the system. You know how you can launch files from the Firefox's Downloads window? There's nothing that prevents a skeleton XUL application from downloading a EXE and then launching it with no user interaction. The dialog that Firefox displays when launching executables is handled by the download dialog, there's nothing that requires it be displayed. (I've written an extension that launched a Windows Control Panel applet before, trust me that there's nothing really preventing XUL applications from being nasty.)

So I'm still left wondering, what was this intended for, and who thought it was a good idea?

Re:What earthly use is "firefoxurl" anyway?!

[BZ]

> what on earth were they thinking when they implemented it?

They didn't implement it. It's a protocol Windows made up based on the names of the registry keys Firefox set to get http: URIs to open in it.

Re:What earthly use is "firefoxurl" anyway?!

[_xeno_]

See, I would have called that a "web-based XUL application" or something like that. A XUL application loaded by a firefoxurl exploit would be at the chrome level, and have full privileges to be nasty.

I think the term "XUL application" would refer to XUL-based applications like Firefox, assuming XULRunner ever gets released. Not XUL pages loaded off the web - which do, indeed, run at the same restricted level as any other webpage.

Re:Kdawson...

[StikyPad]

as yet no winner has been declared

That's only because some newb thinks dupes are evidence of a nonrandom event.

Re:Ok....

[wile_e_wonka]

I could imagine web developers in the position you describe--especially old ones who are used to using IE. They still keep FF on hand to check compatability.

As for myself (I am not a web developer) I have FF installed but don't usually use it--I primarily use Opera.

Re:Opera

[wile_e_wonka]

I'm not sure this wouldn't work on Opera if written specificaly for it (which does still reveal a benefit of Opera--people don't usually think to write code exploiting Opera. It just isn't economical to do so). The reason I say this is because, when I click on the link above, Opera asks if it can open FF. This does not end up being detrimental because then I just end up with FF asking me if it can open FF (instead of asking to open cmd.exe). However, if the exploit were written for Opera, then I imagine Opera would have asked me if it could open cmd.exe instead of FF. With all the people out there who just click "ok" to everything that pops up on their computer (i.e., my wife, despite my attempts to teach her otherwise), this could be a workable exploit.

As for Opera on Feisty--it looks ok to me. The font is different from that in Windows but nothing "whacked up."

Those who ignore history are doomed to....

[martin_henry]

curse the slashdot moderators and die.

Re:Ok....

[dwarfsoft]

MSDN didn't work with Firefox for a while back in the 1.x days. I had IETab to fix that. Seems to work fine for me now though. The local Intranet at work here doesn't get the menus working right (they unroll in the top left hand corner of the screen, no matter where they were supposed to) which makes browsing the intranet a hassle. Other than that I have no issues either.

Most people using Firefox wouldn't be browsing MSDN anyway, and only IT people where I work would be able to have Firefox installed, so its not really a big deal.

Firefox's Fault?

[DavidD_CA]

Here's the meat of the article:

Meanwhile, Kristensen of Secunia said: "A new URI handler was registered on Windows systems to allow Web sites to force launching Firefox if the 'firefoxurl://' URI was called, like ftp:// http:/// or similar would call other applications."

But because of the way the URI handler was registered by Firefox, it causes any parameter--which activates a program to perform a particular task--to be passed from Microsoft's Internet Explorer, or another application, to Firefox, when firefoxurl:// is activated.

An attacker may use "chrome" context--the interface elements of a browser that create the frame around its page displays--to inject code on a user's system that would be executed within Firefox, Kristensen said.

I interpret that as saying that the Firefox installer messed with Windows and Internet Explorer, opening a hole. Is Window/IE really to blame when another application adds "features" that end up being holes?

If Windows/IE were to filter what can and cannot happen through URI handlers, I could see developers crying foul for preventing access and locking out competition.

Further, is the onus now on Microsoft to fix a hole created by Firefox? And once they fix it, and legit things break because of it, who's fault will that be?

Re:Firefox's Fault?

[Vexorian]

I interpret that as saying that the Firefox installer messed with Windows and Internet Explorer, opening a hole. Is Window/IE really to blame when another application adds "features" that end up being holes?

hmm, hell yeah? Why allow such things like letting an installer create a whole protocol anyways ? It looks like the whole idea of letting that happen is pretty lame...

Re:Firefox's Fault?

[DavidD_CA]

Here's why:

http://en.wikipedia.org/wiki/URI_scheme

Apparently a Firefox developer thought it was a good idea, too.

Re:Firefox's Fault?

[BZ]

> I interpret that as saying that the Firefox installer messed with Windows and Internet Explorer

Firefox set up the http: protocol and such to launch it. Windows synthesizes a new URI scheme based on the registry key name used for this and associates this made-up scheme with Firefox. Not much Firefox can do about this Windows "feature".

Re:Firefox's Fault?

[_xeno_]

I just checked. On my system, FirefoxURL is completely stand-alone - it's does one thing, and one thing only, and that's this security hole. It does nothing else. It's not referred to by HTTP or HTTPS (both are currently set to open with Internet Explorer). In fact, it's not referred to by anything at all.

This is with a Firefox 2.0.0.4 install - never upgraded, a straight 2.0.0.4 install. If it's supposed to set Firefox to open with HTTP or HTTPS URLs, Firefox screwed it up, because it doesn't.

Re:Ok....

[(Robo_Bro)]

That's why we have IE Tab. https://addons.mozilla.org/en-US/firefox/addon/141 9

SOMEONE is a little sensitive.

[khasim]

Hey, don't get mad at ME if this "Firefox exploit" depends upon IE being insecure.

An application is only as secure as the system it runs on.

I'll stick to Ubuntu where I have a choice.

If that offends you, too bad. Get a life and stop trying to make a religious war out of an OS.

Re:SOMEONE is a little sensitive.

[Random832]

It's not IE being insecure. It hands firefoxurl: urls off to firefox because firefox registered a URL handler, the same as it hands aim: urls off to aol instant messenger, irc: urls off to whatever IRC client exists that actually bothers to support that (i think mirc did at one point), etc. This is by design, and it's _not_ a bad design. It's the same flaw as the "shell:" url thing that affected firefox, only it's in the opposite direction - with shell: it was windows that provided an idiotic URL handler and firefox that you'd click on it from, here it's firefox providing an idiotic URL handler and you click on it from IE.

Re:SOMEONE is a little sensitive.

[stonecypher]

Responding to yourself as if someone had given you guff over your choice of operating system? ... Karma troll much?

Does it allow extended priviliges

[baggins2001]

Does this exploit create the ability to extend privliges beyond those that the user logged in has?

Re:Does it allow extended priviliges

[Kalriath]

No.

Wait a minute it doesn't seem to work

[baggins2001]

I tried a number of the examples provided at http://www.xs-sniper.com/sniperscope/IE-Pwns-Firef ox.html, but they don't seem to work on my test system.

Re:Wait a minute it doesn't seem to work

[Giorgio Maone]

You're either using NoScript or an O.S. different of Windows.

Re:Ok....

[franksands]

In Brazil, almost all internet banking sites require IE because of this or that. I think there must be some cases like this in other countries.

I read the headline....

[Actually, I do RTFA]

And thought, first my girlfriend, now firefox. I'll see a doctor about it, just stop complaining. You're just giving me performance anxiety.

Highlighting phishing sites is nice, but weak

[Animats]

Just highlighting domains of phishing sites isn't going to be enough. Here's today's list of domains that "sort of look like Paypal". These are after subdomain truncation.
"paypal-checker.com"
"paypal-contact.net"
"paypal-customize.com"
"paypal-erreur2.com"
"paypal-security.com"
"paypal-web-dll-scrnupdateaccount.ici.st"
"paypal-web-scrn-dll-pl-dai-pl-webscrndllfs-wertyu i.ork.pl"
"paypal.powered.at"
"paypal.q.fm"
"paypalaccverify.com"
"paypalcomcgibinwebscrcmd.by.ru"
"paypalcomcgibinwebscrcmm.by.ru"
"paypalcomcgibinwebscre.by.ru"
"paypalconstomers.com"
"paypalct.com"
"paypall.ro"
"paypalmd.com"
"paypalobjects.us"
"paypalsecuritycenter.org"
"paypalverification.org"
"paypel-acc-5.com"
"paypilpal.com"
"paypll-wscr.com"
"paypluspl.com"

These are from PhishTank, which blacklists at the URL level based on manual reports. For SiteTruth", we're in the process of converting to blacklisting phishing sites by the entire base domain. That's because we now see hundreds of entries like "session-624333.nationalcity.com.userpro.tw", which has to be treated as a bad indicator for all of "userpro.tw".

There's collateral damage. There are days when "tinyurl.com" and "notlong.com" get blacklisted, because phishing sites use them. MSN gets complaints about this. Today, anybody running something like "tinyurl" needs to continually check the phishing databases for attempts to abuse their service, or their own reputation is toast.

Mod up

[Bearhouse]

If the lame 'I use Opera post...' gets a 5, then so should yours! I should imagine that most users here do NOT use IE as their default browser, and if using Firefox, have it loaded up with Adblock, Noscript, phishtank...as do I

Here's the solution

[SkiifGeek]

Well, there is always:
http://www.beskerming.com/security/2007/07/11/35/F irefox_-_Remote_hacker_automatic_control

The solution is in there, along with the report. Even when disclosing content that is extremely time sensitive, that information will always be available from our site.

Re:Firefox's Fault? (NO, BOTH's Fault - Read on)

[Anonymous Coward]

From Arstechnica: http://arstechnica.com/journals/microsoft.ars/2007 /07/10/firefox-and-internet-explorer-team-together -for-critical-vulnerability

Thor Larholm, the researcher who discovered the flaw, insists that the blame falls on the back of Internet Explorer. "Firefox is the current attack vector but Internet Explorer is to blame for not escaping quote characters when passing on the input to the command line." He also notes that Internet Explorer behaves similarly with other handlers. "Internet Explorer doesn't filter the input for the irc:// or aim:// URL protocol handlers either. The exploitability on those depend on what arguments each application accepts."

The director of Symantec's Security Response Center, Oliver Friedrichs, believes that both browsers should share the heat. "You have two very complex applications that are not playing well together and leading to a security issue. The components themselves are secure as stand-alone products but not together."

Whats the fuss about?

[cybergen007]

I do not get waht the fuss is all about. If firefox is started from IE that has to ring a bell. Second I get a warning from Firefox that it wants to start an external application and I can click no and nothing happens. I have never before seen that question from firefox so I have run into a website that uses this vulnerability. Beside this happens when you are surfing using IE. If you surf using IE then you are asking for problems in the first place.

Re:Ok....

[AuMatar]

What sites are those? I haven't come across a site that didn't work in Mozilla in 3 or 4 years.

Doesn't work!

[giorgosts]

Neither of these that are mentioned in this link. IE7, Winxp sp2, firefox 2.0.0.4, limited user account. Links only open a blank tab in firefox, and a firefox warning to launch sth that doesn't launch. No new profile, no text.txt (although I've created one as instructed) no cmd, no nothing

Laughing? A less happy feeling

[Futurepower(R)]

I wouldn't call it laughing. "You are coming to a sad realization. Cancel or allow?"

"If you've used Windows Vista for more than 3.7 minutes, you know what UAC (User Account Control) is.. it's the obnoxious, nagging popup window that will be your life for the next 3-5 years... Note: Disabling UAC will lead to a less secure system, so be warned. -- The How-to Geek

Re:Laughing? A less happy feeling

[SEMW]

You are coming to a sad realization. Cancel or allow? It's rather ironic that you're positing that in this thread, since UAC actually prevents the exploit that TFA's talking about.

If you try it on Vista with UAC turned on, it'll fail -- or, at least, it'll give you a warning dialogue (one of these ) -- due to IE's protected mode, which is part of UAC (quick summary: IE runs as an even lower integrity token than normal users, and need privilege elevation to a normal user token to do things like write to anywhere other then temporary internet files and access other programs on the computer -- in this case, Firefox).

Re:Laughing? A less happy feeling

[valintin]

If the dialog is that common I wonder how many people are going to automatically accept running this because they are constantly annoyed by the pop-up?

Re:Laughing? A less happy feeling

[SEMW]

If the dialog is that common I wonder how many people are going to automatically accept running this because they are constantly annoyed by the pop-up? "If the dialogue is that common" -- huh? Where exactly did I imply it was very common? After all, how often is a legitimate website going to want to access other programs on your computer? The only times I've ever seen it are when installing plugins from websites (e.g. quicktime, flash), and this exploit. (And if there *is* a legitimate site that needs to access other files/programs on your computer for some reason, the warning box has an option to not show the warning for that site again).

That said, most of my browsing is done in Opera -- I only use IE for sites that don't work well in Opera (mostly sites that use the WMP plugin) -- so I could be wrong.

Re:Laughing? A less happy feeling

[stonecypher]

Actually, irony is the use of a word to mean something other than its superficial intent.

Re:Laughing? A less happy feeling

[SEMW]

According to my 1979 edition of the Oxford English Dictionary, the use of a word to mean something other than its superficial intent is, indeed, one meaning of irony. Your linked rant is entirely based on the assumption that that is the only meaning; it is not: the OED gives three. The first is your meaning. The second is: "A condition of affairs or events of a character opposite to what was (or might naturally be) expected; a contradictory outcome of events as if in mockery of the promise and fitness of things". So statements like "There is no irony in trying to prevent something and thereby accelerating or worsening it" from the linked article are simply incorrect; such situations fall quite naturally into this meaning. The idea in the article that this meaning is a recent mistake is also wrong; citations for this usage go back to 1649 (although I will give you that your usage was probably the first: citations for that usage go back to 1502).

Re:Laughing? A less happy feeling

[stonecypher]

Yeah, here's the problem: just because you say English works that way doesn't mean that it actually does. See, if you go into court, and say "the law is defined by what I want, not what's on the law books," they'll laugh at you all the way to jail. Just like, in fact, I'm laughing at you all the way to the submit button.

When you can point to an actual language authority making any such absurd claim, lemme know. By the way, some other dude on SlashDot or GeoCities or IBoughtAnOfficialLookingDomain.org doesn't count.

Re:Laughing? A less happy feeling

[allauthors]

You sir, are an pompous ass without a clue-.

I challenge you to find a linguist (Your high-school English teacher who barely graduated college is not a linguist and is most certainly not an authority on language of any kind [except, of course, to her browbeaten high-school students]) who does not agree that a language is 'defined' by usage. Prescriptive definitions arise out of usage, and as the language evolves they quickly become obsolete. Thus while they may serve as useful references for both learning and for identifying universally acknowledged common usages, they most certainly should not be used as authorities for the proscription of usages. Even French, which attempts to be prescriptive [or rather, which the government of one of the nations which speaks it attempts to prescribe] so as to preserve its identity, is de facto if not de jure defined by usage. It is a primary linguistic principle proven by both repeatable experimentation and extensive observation.

See for instance the definitions of gay, nice, ironic etc. from the OED for just a few examples of words whose meanings have evolved significantly over time.

A quick google search would have revealed to you plenty of authorities on the subject.
How about the following two:
The University of Massachusetts at Amherst is hardely "some other dude on SlashDot or GeoCities or IBoughtAnOfficialLookingDomain.org"
The Law Review at Chicago Kent points out (albeit indirectly) the invalidity of your claim specifically with respect to the law

Re:Laughing? A less happy feeling

[Fred_A]

Even French, which attempts to be prescriptive [or rather, which the government of one of the nations which speaks it attempts to prescribe] so as to preserve its identity, is de facto if not de jure defined by usage.

The French Language Academy isn't the government. Speak not of what you know nothing about.

Re:Laughing? A less happy feeling

[SEMW]

UAC doesn't prevent anything, it just warns you about everything and anything, so yes, at one point it might actually warn you about something useful, but that's just a coincidence. Don't be stupid. UAC is a privilege elevation system, not a warning system; it allows you to elevate to perform administrative tasks (or user tasks in protected mode) when necessary, just like sudo in Linux, or authenticate in Mac OS X.

Tried IE in Wine?

[tepples]

and when I try to open this "ie" program:

"~ $ ie
bash: ie: command not found" Internet Explorer is a Windows program. Does wine iexplore.exe work any better?

www.xs-sniper.com is not in the IE whitelist

[tepples]

Close all FF windows
Open IE.
Go here http://www.xs-sniper.com/sniperscope/IE-Pwns-Firef ox.html/ And all I get is a message from my proxy stating that the site is not on IE's whitelist (which includes Windows Update and a few other hostnames) and that one should use the installed copy of Firefox or Opera for other sites. So in order to be vulnerable, you have to be using IE or another MSHTML-wrapper as your primary browser.

Solution for phishing: two-way login.

[master_p]

There is a solution for avoiding phishing: two-way login. Not only the user logs into a site, but the site submits a password to the user during the login sequence. The 2nd password is created during registration. If a site fails to submit the correct password to the user, then it's clearly a phishing site, even if the url is the same.

Re:Solution for phishing: two-way login.

[Random832]

That is a step-by-step recipe for the perfect man-in-the-middle vulnerability.

You give your password, He gives your bank your password, The bank gives him its password, He gives you the bank's password

Re:Solution for phishing: two-way login.

[master_p]

Not if communication is encrypted.

Re:Solution for phishing: two-way login.

[Random832]

If it's encrypted in a way that lets the user verify that it's really the bank that he's talking to, then what's the point in having "two-way login"? If it's not, then all of the above happens, over an encrypted connection between the customer and the thief, and another encrypted connection between the thief and the bank. I assumed you were proposing "two-way login" as an alternative to SSL, not something in addition to it that still won't help if the user doesn't care that the certificates don't match.

Re:this story sucks

[doti]

I heard, directly from the Mozilla guys (Asa and J.T.), that there's a plan to create a Javascript 2 that, combined with SVG, would replace Flash. The strange part is that Adobe itself is taking part of this process.

Re:Regenerated on FF start

[mario_grgic]

I did this on XP as well. You can always remove the FirefoxURL entry from the registry located at

HKEY_CLASSES_ROOT\FirefoxURL

So, go to start Run, type regedit and navigate to this key. Right click on it and choose Delete.

Of course you could also export the entry and save it in a .reg file, should you ever want to put it back.

To put it back, just double click on the .reg file you saved.

Re:this story sucks

[Goaway]

Yes, yes, we know you're still stuck in 1995 when it was cool to hate JavaScript.

The rest of us realize it's actually one of the better languages in use today.

that failed, for me

[ClioCJS]

clicking that link in IE made Firefox try to run CMD.exe, but it still warned me, so i don't see how that's a security flaw.

Re:Opera

[SEMW]

opera looks somehow whacked up when installed on my ubuntu feisty.. must be the font or something???? Have you installed the msttcorefonts package (Automatix installs it, I think, and it's in ubuntu-restricted-extras)?

If so, that may be the problem. The MS fonts just don't render well in Opera on Ubuntu. Arial seems to render incredibly squashed and compressed; and Verdana, by contrast, seems abnormally horizontally stretched, compared to how they render in Windows. None of the fonts seem to be getting antialiased properly when subpixel rendering is turned on. (This is all with hinting set to 'full'; turning that down makes everything go to hell).

That isn't to say I like Bitstream. I don't, much (it's rather too squareish, reminds me of Webdings). But at least the Bitstream set, for all its faults, renders consistently cleanly and legibly under Ubuntu.

The situation hasn't improved with later fonts: I grabbed Segoe UI (a font I've grown extremely fond of on Windows) in the hope that it would have improved things, but no luck -- though fine at very large sizes; at normal sizes it renders very, very thickly, and rather blockily. Certainly nothing like it *should* be rendered.

The latter problem is actually perfectly understandable -- Segoe UI is apparently "specially hinted for Cleartype" which probably translates to a bit of Microsoft improprietry that Ubuntu's font renderer, quite understandably, doesn't understand. But with the msttcorefonts, this shouldn't apply, so I don't really know why they don't work very well under. Some sort of conflict between Opera and Ubuntu's font renderer? Oh well. Anyway, if it is installed, try uninstalling it from Synaptic, and let Opera revert to the Ubuntu default fonts.

Re:Ok....

[SEMW]

If IE tabs are too slow (which they are) and Firefox crashes too often (which it does); have you tried Opera? Best of both worlds.

NoScript installed but javascript enabled!

[giorgosts]

I've got it installed, but all javascript enabled. If you read my previous post, the exploits don't work with my setup.

Re:NoScript installed but javascript enabled!

[Giorgio Maone]

NoScript's specific countermeasures against this exploit are independent from JavaScript permissions.

They prevent specific kind of URLs from being opened from external applications and/or gaining chrome privileges.

Nevertheless, using NoScript but keeping "all javascript enabled" is not best idea I've ever heard of.

Re:NoScript installed but javascript enabled!

[giorgosts]

Wife always disables blocking, cause it interferes with experience. BTW my primary system is linux

Quickies? LTNS!

[Baloo Ursidae]

Whoa! Been a long time since the Quickies happened! And it's not even a Friday!

Some terrifying demo there...

[cbhacking]

I run Vista, have both IE7 and FireFox 2 installed, and at present am browsing using IE7.

Clicking the link first caused IE7 to ask permission to open a program outside Protected Mode (Firefox, in this case). Click OK, and Firefox opens (well, it waits a while then prompts me to restore a session that ended when I last rebooted into Linux). Ok, so I finally get a blank Firefox window, and Firefox prompts me to open an external program (Firefox again, ironically). Click OK to that... and nothing happens. Meanwhile, IE7 throws out an error message stating it can't find the URL "firefoxurl:test" and I should make sure I typed it correctly. I click OK to that, close Firefox, and IE7 states that it can't even find a program that will handle the request.

Overall, I'm not too terrified of these firefoxurl: links. Two dialog boxes (not counting the session restore one), and in the end it did... nothing at all. Oh, the horrors; you might trick me into needing to close error messages! Bah... I really can't say I'm worried.

Demonstration still doesn't work

[cbhacking]

on Vista, using IE7.

1. Click link from IE7:
2. IE7 says it needs to launch another program (Firefox) to handle this URL, that said program will open outside of Protected Mode, and that I should only do so if I trust the website.
3. Click OK, and Firefox starts to open, either with a blank window or the Restore Session dialog followed by a blank window.
4. Firefox says it needs to open an external program (itself, ironically), gives me a few seconds of unintelligible URL reading before it lets me click the OK button.
5. Click OK... and nothing happens in Firefox and no program opens in Windows, so I close Firefox.
6. IE7 tosses up a pair of error dialogs stating that the URL doesn't go anywhere and that the helper application rejected the protocol (firefoxurl).

Terrifying, ain't it! You could trick me into... closing error messages!