New cross browser zero day vulnerability for IE!

Hello malware fighters,

A new dangerous cross browser zero day hole has been found up for IE:
http://larholm.com/2007/07/10/internet-explorer-0day-exploit/
There are no exploits in the wild found at the moment, but why it is announced at Patch Tuesday?
Again, again when you have NoScript extension enabled in FF or Flock, you have nothing to fear
from the arbitrary javascript code for this cross browser command injection hole.

polonus

Well I have NoScript on firefox 2.0.0.4, but more importantly it would appear that you get an external protocol request pop-up notification (see image), contrary to someone saying that it works on 2.0.0.4. Now I believe the alert is a firefox on rather than anything to do with NoScript.

I even gave temp permission for larholm.com in NoScript and I still got the alert, so it doesn’t look as if it is functional on firefox 2.0.04 unless the user gives permission for the external application/process to run.

Security firm Secunia has issued an advisory regarding a newly discovered "highly critical" security flaw in Firefox 2.0 and later, which involves a special URI handler. Although the problem was initially attributed to Internet Explorer by researcher Thor Larholm, Firefox is the culprit.

According to Secunia, “Firefox registers the “firefoxurl://” URI handler and allows invoking Firefox with arbitrary command line arguments.” This means that a malicious site visited in Internet Explorer could pass parameters using that URI handler that would be run automatically in Firefox, without any sort of validation. The firm suggests not visiting untrusted sites until the problem is resolved.

http://www.betanews.com/article/Highly_Critical_Flaw_in_Firefox_20/1184081542

Some interesting comments:

By Scotch Moose posted Jul 10, 2007 - 2:35 PM

The reason for this is that the FirefoxURL handler was added in Firefox 2.0.0.2 as part of a Vista compatibility change. Microsoft asked for it.

The lack of input validation is still a flaw in IE, even if Firefox could have registered their URL protocol handler with DDE instead.

I don’t think we will see Firefox fixed to not accept command line arguments. And don’t stay awake waiting for Microsoft to validate input before launching a URL handler. Your best bet is to remove the URL protocol handlers, that is if you must run Windows.

Really, who thinks launching executable programs with a browser based on the content of web page is a good idea? This is even worse than ActiveX.

By bourgeoisdude posted Jul 10, 2007 - 2:54 PM

“Really, who thinks launching executable programs with a browser based on the content of web page is a good idea? This is even worse than ActiveX.”

Sadley, Dell, HP, Norton, McAfee, Trend Micro, and countless other manufacturers use this technology for their driver reinstall discs/online virus scans/active updates/etc. It’s tough to kill it because so many people are using it…

By zxo20000 posted Jul 10, 2007 - 2:49 PM

totally agree

By yohimbe9 posted Jul 10, 2007 - 12:48 PM

It starts to make you wonder about all of the other protocol handlers that are installed. A quick registry search in HKCL for “URL Protocol” found an Acrobat (acrobat://), Adobe Bridge (adobebridge), iTunes (daap://, itms://, itmss://, itpc://, pcast://) as well as several for WinAmp, Outlook and Real

Secunia report:

Description: A vulnerability has been discovered in Firefox, which can be exploited by malicious people to compromise a user's system.

The problem is that Firefox registers the “firefoxurl://” URI handler and allows invoking firefox with arbitrary command line arguments. Using e.g. the “-chrome” parameter it is possible to execute arbitrary Javascript in chrome context. This can be exploited to execute arbitrary commands e.g. when a user visits a malicious web site using Microsoft Internet Explorer.

The vulnerability is confirmed in Firefox version 2.0.0.4 on a fully patched Windows XP SP2. Other versions may also be affected.

Solution:
Do not browse untrusted sites.

Disable the “Firefox URL” URI handler.

http://secunia.com/advisories/25984/

Demo:

This is a simple demo of Cross Browser Scripting through the use of registered URIs When Firefox2 is installed, it registers the "firefoxurl" URI in the Windows Registry This allows applications which render HTML (like Internet Explorer) to spawn an instance of Firefox. The danger arises when parameters that are part of the firefoxurl: are passed directly to the Firefox.exe as options, without validation. By using the firefoxurl URI, it is possible to use Internet Explorer (or other windows based browsers) to launch FireFox and immediately launch Javascript Code. It is also possible to create a user profile, load arbitrary firefox options, and install global extensions, all without user consent. Attacks using the firefoxurl URI will probably be initiated through the use of XSS or CSRF Although these examples are very simple, other, more malicious attacks can probably be initiated.

A demonstration of each vulnerability is given below. The user must have both IE and FireFox installed. Although there are several ways to initiate this vulnerability, this particular example can be launched by doing the following:
1 - Close all Firefox browser windows
2 - Browse to this page with Internet Explorer and click one of the demonstration links
3 - Enjoy
4 - Close all Firefox windows before clicking on the next link

http://www.xs-sniper.com/sniperscope/IE-Pwns-Firefox.html

Security researchers can't decide whether it's in IE or Firefox By Dan Goodin in San Francisco → More by this author Published Wednesday 11th July 2007 00:50 GMT Email and Web Compliance: Awareness Pack - Free download

A serious vulnerability that causes Internet Explorer to launch Firefox and execute a malicious payload is sparking debate about exactly who is responsible for the flaw.

The vulnerability, which was widely reported on security blogs, allows an attacker to remotely execute malicious code on a machine that is running IE but also has the Mozilla browser installed. By luring an IE user to a malevolently crafted site, the attacker can cause Firefox to execute the code without first vetting it for security.

The saying about success having many parents but failure being an orphan seems fitting here. Window Snyder, who heads security at Mozilla, wrote today that Mozilla developers will patch Firefox so it no longer accepts bad data from IE. But she stressed that only people browsing with the Microsoft browser were vulnerable to the attack.

“We recommend that people use Firefox and as always take care when browsing unknown websites,” she wrote.

For its part, Microsoft representatives said company researchers have “investigated the claim of a vulnerability in Internet Explorer and found that this is not a vulnerability in a Microsoft product.” Jesper Johansson, a former senior security strategist for Microsoft, similarly argues that “most definitely” the problem isn’t caused by IE.

“Firefox fails to properly validate the parameters, and any fix will have to come from Mozilla, not Microsoft,” he wrote in a blog entry.

A proof of concept exploit found here uses IE to hand off maliciously-scripted code to a Firefox handler known as “firefoxurl.” Handlers, which also include strings such as “ftp” and “aim,” are found in the address bar and in many cases can be used to get Firefox to carry out certain actions.

Roger Thompson, CTO of Exploit Prevention Labs, says Microsoft shares culpability because IE fails to properly validate the input before passing it along.

“I think it’s an IE issue mostly, because if you access the exploit directly with Firefox, FF warns you that something bad is happening and advises you to not do it,” he said in an instant message.

http://www.theregister.co.uk/2007/07/11/ie_firefox_vuln/

I think the key here is that You have to be using IE browsing on a compromised/iffy site and click on a link that passes parameters to launch firefox.

According to Secunia, "Firefox registers the "firefoxurl://" URI handler and allows invoking Firefox with arbitrary command line arguments." This means that a malicious site visited in Internet Explorer could pass parameters using that URI handler that would be run automatically in Firefox, without any sort of validation. The firm suggests not visiting untrusted sites until the problem is resolved.

So to me yes there might be a vulnerability in how firefox handles the parameters (hopefully soon to be patched), but if you aren’t using IE as your default browser this isn’t an issue in firefox, since you can click the same link whilst running firefox and you get the alert image I posted in reply #1.

I think the key here is that You have to be using IE browsing on a compromised/iffy site and click on a link that passes parameters to launch firefox.

Quote
According to Secunia, “Firefox registers the “firefoxurl://” URI handler and allows invoking Firefox with arbitrary command line arguments.” This means that a malicious site visited in Internet Explorer could pass parameters using that URI handler that would be run automatically in Firefox, without any sort of validation. The firm suggests not visiting untrusted sites until the problem is resolved.

So to me yes there might be a vulnerability in how firefox handles the parameters (hopefully soon to be patched), but if you aren’t using IE as your default browser this isn’t an issue in firefox, since you can click the same link whilst running firefox and you get the alert image I posted in reply #1.

The link says it more succinctly:

IE-Pwns-Firefox.html

;D

Hi FwF,

Mozilla’s Window Snyder let us know that the problem only occurs with people that use Internet Explorer. “It is important to know, that when you use Firefox to surf the world wide web, you are not vulnerable to this attack. That is why we advise people to use Firefox as their default browser, and as always to be cautious when visiting unknown websites.” see:
http://blog.mozilla.com/security/2007/07/10/security-issue-in-url-protocol-handling-on-windows/

Microsoft’s Jesper Johansson counterattacks: “Firefox fails in validating the parameters, and a solution has to be sought at Mozilla’s, and is not to be expected from Microsoft.” Mozilla already told that it would patch the hole with Firefox 2.0.0.5. see:
http://msinfluentials.com/blogs/jesper/archive/2007/07/10/blocking-the-firefox-gt-ie-0-day.aspx

Security researcher Larholm, the man that found up the hole, keeps insisting that Internet Explorer is at the root of the problem, while it does not “escape” quotes, while re-directing input to the command line.
“You cannot blame Firefox for doing what it is told to do, the core problem is that IE makes us specify more items than it was meant to at the outset.”

But the crux of the matter is that NoScript has saved our glorious behinds here again, when will they bring in this unique security add-on into Firefox and Flock by default?

polonus

Hi Damien,
Those of us who use a plug-in to open a link in IE while using Firefox as our default browser
need to use extra caution any time this option is used.

Well, bob 3160, that is why this is called a “cross browser” vulnerability. But NoScript enabled for unknown websites with possible malicious code (good for us live exploits weren’t as yet discovered) protects you for the full 100 % as it has done with so many Javascript driven embedded malware code.
If you do not have NoScript installed inside FF or Flock you loose out on a lot of serious browser security.
It can save your “hide”, really it can, also for exploits that haven’t been patched or won’t even!!!

Damian

Hi malware fighters,

Someone showed that it is possible to open local files on a computer from inside firefox of a visitor of a website via the resource:// URL Protocol handler in Firefox. As an example let us consider the following link: resource://gre/greprefs/security-prefs.js. This link reads the file security-prefs inside your installation folder of Firefox (that is: C;/programfiles/mozilla firefox/greprefs/security-prefs.js). Mozilla thought to block this by blocking opening of files outside the firefox folder by blocking the commands: …\ en …/ commando’s (to go back one folder). By changing …\ into …%5c (the ASCII-code for a slash) you can circumvent this block, and open up the file resource.txt on the C-sdrive as follows (e.g.):

To cut down abuse Daniel Veditz posted a bugfile in Bugzilla, so Firefox-developers could patch this 0-day hole. Mozilla has launched a patch for Window-users, but it is still unpatched for Linux and Mac. But it is still possible to read the Firefox folder, that is files like update.xml, install.log and browserconfig.properties (those are your settings, like the start page) to be read from malicious sites.

On http://larholm.com/2007/05/25/firefox-0day-local-file-reading/ you can see the hole is still “alive and kicking”, the info is based on data in files inside the Firefox-folder.

Shortly an update will be launched to tackle the whole problem. Best solution is to take out all of the whole resource://-protocol and forbid it to Internet sites in Firefox.

polonus