A serious browser vulnerability, but whose?

bugs

It's not a bug, just an(other) undocumented feature.

is so firefox.. :)

But firefox is registering 'firefoxurl' as a uri scheme to pass info to...

IE 1 FF 0

In this case, if IE decided to do any parsing, MS would be blamed for somehow controlling the user.

IE can handle that data, therefor passes it along. Firefox should KNOW better than to accept data from ANYWHERE (be it IE, a browser, a link, etc) without validating it.

You can't say, well, I trust IE so its IE's fault. It's like me saying, he told me his name was Shirley, so I believed him. It's HIS fault.

It's not Firefox, it's BOTH!

Well, in reality, it is both. IE's fault for being exploited, and also Mozilla's fault for not properly parsing the input from IE.

both of them

if ie passes on malicious code it's an ie bug.

if ff executes bad code without checking it first it's an ff bug.

both sides are clearly involved and both sides need to patch their browser quick instead of passing on the responsibility to the other side. that's kinda childish.

Just use Opera

None of this would be a problem if more folks were using Opera. The proof of concept just loads a page with a box and a string of text on it and then does nothing when viewed in Opera.

If this Were any more clever

You could put a tail on it and call it a weasel!

Definitely firefox

I'm no IE fanboy, but any first-grade programmer knows that if you're accepting input from other programs, the onus is on you to validate it. Trusting data fed to you by external sources is idiocy. Firefox should own up to this one and keep its longstanding tradition of putting user security ahead of its own interests.

The problem is with both...

A downcheck to Microsoft for allowing the internals of IE to be corrupted to pass a bad command...

A downcheck to Firefox for allowing a piece of external data into its internals without first checking it.

While I have not written anything for a Browser, I write for quite a few database systems that have to interface with various other systems; and the first rule is - external data is *always* suspect (internal data is potentially suspect).

Simple solution

Surely a simple test will sort this one out: can any other browser trick firefox in a similar way?

If you can't get Netscape, Safari or Opera to pass the bad info then I'd say it was an MS issue. If you can, though, it's an FF issue.

finger pointing

At least Mozilla said they'll patch this. Let's see what happens when we start seeing the "use IE to hand off bad code to Word or Outlook" errors. I'm sure those are around the corner. Who's to blame then? :)

Tough to say- but attitude is important

Tough to say where the flaw really is. The security risk comes using IE, but FF executes the bad code. The attitude is the thing to note here. MS will not dare admit that any of it's programs ever have any kind of flaws of any kind. FF came out and said we'll patch it to not accept anything from IE. IE SHOULD be coming out saying we'll patch it not to pass anything to FF. Mozilla is getting things taken care of, MS is trying to assign blame to someone else and not doing anything about it. Whether the flaw is in FF or IE doesn't matter, the path is closed off so the exploit will not work anymore, but the fact that only one gate is closed because of attitude (read God-complex) is a problem.

Why is there a custom FF handler in the first place?

The real question is, why is there a custom FF handler in the first place? There should be no need for such an additional, non-standard construct and putting one in is just asking for trouble.

I'm a FF fan, but in this case IE appears to be doing what it's meant to do - passing data onto a third party handler application. It's not it's fault that the data is incorrect or invalid, it's for the third party handler application to do that checking, besides, there's no way that IE can know the exact validity of a URI for a third party handler.

yeah yeah whatever

Well I'm running Firefox from the PortableApps suite and the only thing the Xssniper managed to do was create a new profile...It's gotta be IE

Custom handler

I agree with Nick, how is this supposed to be an MS problem? IE receives a request which needs to be handled by a 3rd party app, it doesn't understand it, can't do anything with it (and obviously isn't vulnerable from it), so passes it on to the app which can process it.

It's all very well saying that IE should block it, but imagine the outcry there would be if IE started blocking all requests to 3rd party apps which it didn't know how to handle! People would then complain that MS was stopping 3rd parties from developing new things since they'd be beholden on MS to update IE to understand their new tech. It's a no win situation for them.

Looking at it slightly differently, what would happen if there was a bug in a 3rd party app which wasn't a browser? Say Adobe Acrobat had a vulnerability relating to opening online PDF's? IE doesn't know about the internals of a pdf, it just knows that they should be passed to Acrobat. Should it block the request because it doesn't understand it, or should the onus be on Acrobat to make any required checks when it is passed the file to open?

It's both

I agree with previous posts... Its both IE and Firefox.

Problem? Just fix it.

Browsers are software. All software have bugs. The reason I use Firefox and not IE is that Mozilla has a culture of fixing and improving their product. Microsoft, not so much.

As above, so below

I agree it is the joint responsibility of IE and Firefox. However, why take chances? Thats why i'm writing this from a mac. :D

And the bug belongs to ...

IE... Why?

Because within a few days firefox will be fixed, and IE will still have its half of the bug. The question that should always arise when multiple browsers are affected by the same bug: "Which one will be fixed first?"

What's all the fuss about?

"Attacks using the firefoxurl URI will probably be initiated through the use of XSS or CSRF

Although these examples are very simple, other, more malicious attacks can probably be initiated."

The FF addon NoScript handles this very nicely by blocking XSS, if I'm not mistaken.

So, I guess I'm safe...

Besides, the exploit needs that the user have FF2 installed *and* use IE.

Surely someone who has FF only uses IE to go on *trusted* and *poorly made* websites that only work with IE, like train or hotel reservations, company intranet...

It's unlikely that a FF user will go browser *doubtful* (*cough* porn *cough*) sites with IE.

Could be either, they're both flawed

I have found that without NoScript, Firefox lets in more bugs than a entomologist looking to restock his lab. Plus having to allow things when I want to use a website properly is annoying. IE7 blocks things automatically and I lose no functionality.

In fact for quite some time now I have had no problem when using IE7.

The reason why I might think of IE7 is because all Microsoft products are flawed and always critically, and they always need updates. They never get things right.

Nevermind whose flaw it is....

Is that woman really called "Window", has she a brother called "Door" .... or is this a modern extension of the urban myth that some cultures call their children after the first thing they see when their sprog is born ... e.g. "Two dogs shagging".

FF should not execute arbitrary user input!

I haven't read enough into this to learn exactly how the exploit works. It would appear that as a user I can run a command like:

firefox http://www.test.com

and get FF to load http://www.test.com similarly I can run

firefox "firefoxurl://foo" –argument "my value/"

which also seems reasonable.

Programs should be written in such a way that they can prevent the user causing damage, therefore this is a problem with FF not IE.

(The fact that IE can call firefoxurl is irrelevant, the bug, imho is with FF willing to take arbitrary, unchecked, user input)

I'd be interested to learn if others agree with this viewpoint.

Charlie

that's kinda childish

It's all kinda childish, like 99% of forum discussions on the Net. Why ? Because it's mostly children (meaning fanboys) that participate.

I'm surprised that the rhetoric here has remained quite calm and rather level-headed. Must be the moderators putting down 90% of the comments.

re: If this Were any more clever

Sure you don't mean an iceweasel? No ie collaboration going on there...

Its neither!!!

I thought I would just introduce another angle on it!

Definitely FF

Much as I'd like to join in an IE-bashing spree, this one is definitely Firefox at fault. An application should be able to take anything thrown at it from any input source and deal with it. If there's a way of injecting something from an uncontrolled source that bypasses some of the validation checks then that's definitely a bug.

Yawn

Who cares? I have a life.....

Title

"Jesper Johansson, a former senior security strategist for Microsoft, similarly argues that "most definitely" the problem isn't caused by IE."

Poor old Jesper - not only did he have one of the "top 10 worst jobs on Earth", but of course he lost his job some while ago when Microsoft realised that they didn't *need* any security in their products, so why bother having a strategy...?

Oh, and Jesper adds that the world "most definitely" isn't round, and that he "most definitely" isn't writing with a big green wax crayon because, where he now is, they don't let him hold anything sharp.

NoScript

Notice that Firefox users with the NoScript add-on installed have been already protected both from MacManus/Larholm remote code execution and from Rios "Universal XSS" since June, the 22th, see http://noscript.net/changelog#1.1.4.9.070622

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' "Universal XSS" PoC), no matter if attempted through the "firefoxurl:" handler (like in this specific case) or by other yet unknown means.

Hence, these protective features are here to stay, since the upcoming Firefox 2.0.0.5 just fixes the "firefoxurl:"/command line case.

Funny

Once again... the almighty Microshaft brings about more trash to the world..

Not so good that firefox did that either.... but thats secondary.

IE is to blame first and foremost because it's the "weakest link".

Honestly... to blame firefox means you need to blame the entire operating system for letting it happen.. not to mention the winblows firewall...err... wait a second.. i already do... never mind.

Missed the obvious

...If FF is installed and you are running IE to browse the web it's the users fault.

No problems here...

... but that's probably because I don't run Firefox, never have done on this system. Why would I want to? I ran FF on a previous PC long enough to find out that it doesn't work too well with The Internet... *dons asbestos coat in preparation for flame attack* ;-)

Get the facts before you lay blame

1. What are the standards for passing requests on?

If the request should just be passed with no regard to content then IE is not contributing to the problem, if however there is a standard for passing on this request and IE is not adhering to it then is is adding to the issue.

2. Should FF assume it only gets 'clean' data?

This is the same question from the other side, however if there is no agreed standard then FF should validate this data (some have argued that this should be validated even without a standard, which has some mileage, take ever expanding jpg's as a similar issue)

In summary, FF will be fixed to stop this issue because IE can send bad data, if it's not IEs job to validate the data then it's not it's fault.

It depends

Does the browser security depend on where the data comes from - if it is the wild internet, be cautious - if it is from the local hard-disk then less cautious. Like the SQL example posted above - external data watch out - internal data be cautious.

I imagine this crack works by Firefox assuming data from IE is good or IE saying the data is good (i.e. local) and Firefox believing IE or both.

IE should not say passed through data is safe, if it does.

Firefox should not assume data is safe, if it comes from a source with lax credentials.

What does the firefoxurl:// URI do exactly?

The only references I can find are to this vulnerability. A cursory test returns a warning that sources should be validated and there is a delay before a 'launch application' button in the dialogue ungreys itself. Running firefoxurl://notepad.exe and pressing 'Launch Application' generates a new tab with the warning dialogue. Not a good testing environment but it must take a bit of work to find these things out.

It's the user's fault!

It's the user's fault for using IE. They have Firefox installed, why not use it? As much as it pains me to say it, this seems like it'd be better for Firefox to be fixing. It's the one accepting the input.

Re: IE 1, FF 0

Er, hardly FF 0 :) No fair starting to count on one of the rare occasions when a problem *might* be attributable to the competition turns up. That's like if a football team winning 20-0 scored one own goal and the opposition started dancing around chanting "one nil, one nil." ...

Borrowing from Brazil...

SAM:

You got the wrong URL.

JACK

I did not get the wrong URL. I got the right URL. The wrong URL was delivered to me as the right URL! I accepted it, on trust, as the right URL. Was I wrong? Anyway, to add to the confusion, it crashed on us. Which, had it been the right URL, it wouldn't have done.

I don't really care whether or not it's IE or Firefox. Actually, I'll fall into the 'It's both' camp. But the important thing is the response. To work to make sure it won't happen again, regardless of whose fault it was, is the correct response. To do nothing beyond finger pointing is not the correct response.

I run FF but...

... I can't find a Linux distro that ships with IE and Microsoft doesn't seem to offer their browser ported to 'nix. I feel deprived.

On a less facetious note, I'm not entirely sure why real-world users would fall foul of this cross-browser handler exploit. If they have FF installed, one assumes they'd use it in preference to IE except for sites which rely on M$ tech (Active X and so on) or IE ident in the browser header. In the latter case, there's an FF add-on to spoof the useragent header string. Or am I missing summat?

BTW, is 'facetious' the only word that contains all five vowels in alphabetic order?

Is IE partly to blame?

I've just attempted a number of different ways of launching this exploit, but can't seem to get it to execute except from IE.

* Attempting to launch it by pasting the URL into FF shows a warning with the full URL. Accepting this warning just brings up another warning about "firefoxurl:test". Accepting this one just brings up another, etc, creating a new tab each time.

* Attempting to launch it via the ShellExecute API doesn't work. FF warns about "firefoxurl:test", not the entire URL.

* Launching the URL from IE (either via the link or pasting the URL into the address bar) causes the exploit to run.

It certainly seems that IE is partly to blame, because it does something different in how it executes these links. Perhaps MS should patch IE so that it uses standard mechanisms to launch these links, rather than whatever method it currently uses.

Ubuntu Smugness

Windows - ROFL

Re-affirms my disbelief of people porting IE to Linux via WINE. How many slaps in the face like this do you need before you realise that no-means-no? I'm with Max - wait until this results in shots at winword.exe, cmd.exe, rundll32.exe, explorer.exe .. etc ad nausea .. you can almost sense the silent update coming ..

.*a.*e.*i.*o.*u

> BTW, is 'facetious' the only word that contains all five vowels in alphabetic order?

No, search via;

[b-d,f-h,,j-n,p-t,v-z]*a[b-d,f-h,,j-n,p-t,v-z]*e[b-d,f-h,,j-n,p-t,v-z]*i[b-d,f-h,,j-n,p-t,v-z]*o[b-d,f-h,,j-n,p-t,v-z]*u[b-d,f-h,,j-n,p-t,v-z]*

Abstemious

Abstentious

Annelidous

Arsenious

Avenious

Caesious

[Facetious]

Materious

Placentious

Tragedious