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]

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:Oh my

[MrNaz]

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 being stupid. We can do bugger all about this." It's not often MS can legitimately pass the security buck, I'm surprised they didn't ride it for all it's worth this time.

Re:Oh my

[martin-boundary]

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

[Fred_A]

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:Microsoft do it again

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

Want to disable it alltogether ?

[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:Oh my

[Intron]

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:It's the Usual M$ Sabotage and FUD.

[Macthorpe]

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.

Re:Oh my

[jimbojw]

For anyone looking for more information about this problem, here you go:

• Affected OS: Windows
• Affected Browser(s): IE 7 + Firefox (together)
• Cert advisory: https://www.kb.cert.org/vuls/id/403150 [cert.org]
• Secwatch advisory: http://secwatch.org/advisories/1018594/ [secwatch.org]

Here are some useful excerpts from the Cert advisory:

Internet Explorer 7 has changed how Microsoft Windows parses URIs. This has introduced a flaw that can cause Windows to incorrectly determine the appropriate handler for the protocol specified in a URI. This flaw appears to rely on having a "%" character in the URI.

Publicly available exploit code uses Mozilla Firefox as an attack vector for this vulnerability. For more information, including workarounds, please see VU#783400 [cert.org]

It seems that the injection mechanism is to use Firefox, but the exploit requires IE 7 to be installed on the victim's computer.

Interesting excerpts from the secwatch advisory:

The vulnerability is due to an input validation error handling system default URIs with registered URI handlers such as "mailto", "news", "nntp", "snews" and "telnet". This can be exploited to execute arbitrary commands when a user e.g. using Firefox visits a malicious website with a specially crafted "mailto" URI containing a "%" character and ends in a certain extension (e.g. ".bat", ".cmd")

Confirmed on a fully patched Windows XP SP2 and Windows Server 2003 SP2 system using Firefox version 2.0.0.5 and Netscape Navigator version 9.0b2. Other versions and browsers may also be affected.

In the comments to this article [betanews.com] a user by the name of kruador points out:

This is utter rubbish. ShellExecuteEx wasn't updated with IE 7.0. It is a core OS feature - on Windows XP SP2 systems the most recent update was in the MS07-006 security update.

All this function does is look up the URL protocol handler in the registry - for example, http: is at HKEY_CLASSES_ROOT\http - and look for the shell\open key. If a ddeexec key is found under that key, it uses DDE to send the URL to the registered program. If not, it runs the command under the command key, replacing the %1 in the command line with the URL to be processed.

IE uses ShellExecuteEx whenever it encounters a URL protocol it does not handle internally - basically only http [slashdot.org]:, https: and ftp [slashdot.org]:. The Windows Explorer 'Run' dialog calls ShellExecuteEx when you enter a URL into the dialog (in fact, when you enter *anything* into the dialog). It's how Explorer locates a program when you double-click a document file.

The question here is a difference of opinion over whether certain characters should be escaped in the command line or not. The behaviour of ShellExecute[Ex] has not changed. Microsoft are simply saying that Firefox has to cope with whatever it's presented with; Mozilla are saying it would be nice if certain characters were escaped.

[UPDATE:] I have since discovered that Internet Explorer decodes URL-encoded (%-encoded) characters and passes the decoded version to ShellExecuteEx. This allows an attacker to inject " characters into the command line, terminating the URL argument, and allowing further command line options to be specified.

And most importantly, he concludes with:

The simplest workaround is to place a special command line option in first position (included in the command line in the registry, before "%1") that indicates that the rest of the command line came from a URL protocol handler and should be treated with caution.

Sounds like some registry hacking could solve the problem.

Problem is not Firefox.

[twitter]

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, mentioned as "a browser", sends the crap to Firefox and will do the trick on it's own. Also, as we have seen before, this was not a problem before IE7 [slashdot.org].

Re:Care to provide details?

[Opportunist]

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:Problem is not Firefox.

[Macthorpe]

By using the same URI Windows calls Firefox on Windows uses.

Can I have this in English, please? I think you're trying to say that the 'firefox://' URI is a native Windows function, but it's not. Firefox registers it on install.

Those would probably be the ones downgraded by IE7 that created the problem in the first place

How can you downgrade a URI? It's a handler. It passes whatever is in it straight to Firefox without being edited, which is why this problem is happening in the first place.

This explains why there was no problem before IE7 and the nebulous assertion that other "browsers and applications" have the same problem.

Can you prove they don't? Run some tests for me. The people in the article have and they disagree with you.

Chances are that this is going to balloon out to anything web enabled on Windoze.

Like what? Give me an example.

Re:Problem is not Firefox.

[dedazo]

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.

Re:Problem is not Firefox.

[Anonymous Coward]

Wait, let me get the steps straight here:

1. Internet Explorer is given a URI with the protocol 'firefox://'
2. IE doesn't recognize protocol as one it handles internally
3. IE checks the registry for a protocol handler matching 'firefox://'
4. IE finds Firefox.exe
5. By specification, it is the protocol handler's responsibility to check its own inputs, so IE launches Firefox.exe, with the unchecked URI on the command line, expects Firefox.exe to do its job, and considers the hand-off complete
6. Firefox starts and, due to a flaw in its input check, craps the bed

And somehow this is Microsoft's fault? Because Internet Explorer doesn't make uninformed assumptions about the format of the URIs for somebody else's protocols? Oh, and if Firefox isn't installed, step 4 fails, and IE simply displays a message to inform the user that the firefox:// protocol is unknown. The exploitable code is never run, because the exploitable code isn't installed. But that's still Microsoft's fault, simply because they exist, right?