SillyDog701

[J-M]

A new Mozilla Firefox "Host:" Parameter Remote Buffer Overflow Vulnerability warning was released recently. Its risk level is Critical Risk (4/4), highest from French Security Incident Response Team.

From the advisory:

A vulnerability has been identified in Mozilla Firefox, which could be exploited by remote attackers to execute arbitrary commands. This flaw is due to a buffer overflow error in the "NormalizeIDN" function when handling specially crafted URLs embedded in "HREF" tags, which could be exploited by remote attackers to take complete control of an affected system via specially crafted Web pages.

They say Firefox version 1.0.6 and prior are affected.

More details at http://www.security-protocols.com/modul ... e&sid=2910 too. According to the report: "Vendor Status: Mozilla was notified"

Edit: title was shortened/J-M

UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fi-FI; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

[J-M]

Updated information available:

Now they say Netscape 8 is affected too:
http://www.frsirt.com/english/advisories/2005/1691

Secunia company has their new advisory too:
http://secunia.com/advisories/16764/

Their title used is Firefox URL Domain Name Buffer Overflow, severity level is Highly critical (4/5) and they have informed FF 1.5 Beta 1 vulnerable too.

UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fi-FI; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

[J-M]

Mozilla Suite 1.7.11 is affected as well:

http://secunia.com/advisories/16767/

UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fi-FI; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

[Antony]

The vulnerability is caused due to an error in the handling of an URL that contains the 0xAD character in its domain name. This can be exploited to cause a heap-based buffer overflow.

So what is the [tt]0xAD[/tt] character?

And both sites indicated nothing relating to platform? Did they (or Tom Ferris) simply unacceptably assume Windows is the default platform? or they've tested with all supported platforms (Mac, Linux and Windows)?

UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/412.7 (KHTML, like Gecko) Safari/412.5

[Antony]

There's something interesting from BetaNews: Security Vulnerability Threatens Firefox:
A security researcher has issued an advisory on a new vulnerability in Firefox that could lead to the remote execution of arbitrary code. The flaw was first reported to Mozilla developers by Tom Ferris earlier this week, but he opted to publicly disclose the problem following a disagreement.

The vulnerability relates to Firefox's handling of IDN, or international domain names, and can be exploited by long Web links that contain dashes. The flaw causes a buffer overflow and opens the door for malicious code to be run on a PC.

...

Ferris recently discovered a flaw in Internet Explorer 6, which he reported to Microsoft in August. He did not disclose details on that vulnerability, however. Ferris was also credited by Microsoft for discovering a security flaw in the Remote Desktop Protocol.

BetaNews says it's for PC. Is Mac safe?

Exactly, what was the disagreement? Ferris did not disclose details on MSIE's vulnerability, but opted to disclose the Firefox vulnerability?
Or shall I ask, was Mozilla Foundation so mean to Tom Ferris?

UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/412.7 (KHTML, like Gecko) Safari/412.5

[DJGM]

Eitherway, looks like Mozilla.org have their work cut out for them at the moment. Aside from the
ongoing preparations for the next major Firefox release (v1.5) it seems quite likely that a v1.0.7
security update release is on the horizon for the existing Firefox 1.0.x series.

And even if there's a possibility of this problem affecting only Windows users of Firefox, that is
most likely the majority of the entire Firefox userbase affected. And with the severity of this
bug being reported as "high", Mozilla.org are going to have to be quick (as they usually are)
in sorting out a fix. Otherwise, IE fanboys will be gloating, if they're not already!

Also, since the only just released Firefox 1.5 Beta 1 is possibly affected by this bug, it looks
like Beta 2 might have to be released sooner than planned to help minimise any possible
exploitation. Or, at the very least, a re-issue of Beta 1, complete with patch . . .

UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

[J-M]

Mozilla Foundation has published a security advisory entitled "What Mozilla users should know about the IDN buffer overflow security issue", which includes detailed protection instructions and the following information:

The first method is to install a small download and the second method is to manually change the browser configuration.

The security advisory is located at http://www.mozilla.org/security/idn.html

What is the the second method? It's the following workaround:

Manually Configuring the Browser

* To manually change the browser configuration, follow these instructions:
1. Type about:config into the address field and hit Enter.
2. In the Filter toolbar, type network.enableIDN.
3. Double click on the network.enableIDN item to toggle the value to false.

Technically they are not saying that this disables IDN support from the browser.

UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fi-FI; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

[J-M]

Mozilla Foundation has now .xpi file for this purpose, just found it from http://ftp.mozilla.org/pub/mozilla.org/ ... 6/patches/ FTP server.

Unofficial
======
.xpi package URL to disable IDN support automatically
======
Unofficial

http://ftp.mozilla.org/pub/mozilla.org/ ... 307259.xpi

Here in Finland we can register localized .fi domain names (more information at press release Letters å, ä and ö possible in fi-domain names as of 1 September 2005 at http://www.ficora.fi/englanti/ajankoht/letters.htm )

Manual testing:
When browsing to [tt]http://www.säkylä.fi[/tt] FF1.0.6 shows the following real URL:
http://www.xn--skyl-load.fi/

Testing 307259.xpi package (yes, it's Bugzilla number too) now.

UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fi-FI; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

[J-M]

Patch file http://ftp.mozilla.org/pub/mozilla.org/ ... 307259.xpi is now ready, tested by MF and public.

When tested with FF1.0.6 it added the following string to user agent:

...Gecko/20050717 (No IDN) Firefox/1.0.6

Disabling IDN breaks the use of localised Finnish ä, ö and å characters in domain names. I believe that situation is similar in Sweden too.

UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fi-FI; rv:1.7.10) Gecko/20050717 (No IDN) Firefox/1.0.6

[J-M]

If someone want try to use [tt]ä[/tt], [tt]ö[/tt] and [tt]å[/tt] characters in domain names (Windows Character Map has those characters) there is the following official address available: [tt]http://www.viestintävirasto.fi/[/tt] (Viestintävirasto is the Finnish Communications Regulatory Authority registering IDN domain names, this address redirects to http://www.ficora.fi ).
Is there many SD701 readers using IDN characters daily and having possible problems in the future?

UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fi-FI; rv:1.7.10) Gecko/20050717 (No IDN) Firefox/1.0.6

[Antony]

Is there many SD701 readers using IDN characters daily and having possible problems in the future?

Not me, I don't visit domain names with IDN characters that I am aware off.
However, the two examples you gave work perfectly under Safari (tested with Safari v2.0.1, Mac OS X v.10.4.2).
( [tt]http://www.säkylä.fi/[/tt] and [tt]http://www.viestintävirasto.fi/[/tt] )

UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/412.7 (KHTML, like Gecko) Safari/412.5

[Alice]

Patch file http://ftp.mozilla.org/pub/mozilla.org/ ... 307259.xpi is now ready, tested by MF and public.

When tested with FF1.0.6 it added the following string to user agent:

...Gecko/20050717 (No IDN) Firefox/1.0.6.

I installed the 307259.xpi patch in Firefox 1.0.6 and noticed that it removed the (ax) portion of my Firefox 1.0.6 UA (showing that the ActiveX plugin is installed). I'm not sure why the UA should show "No IDN" when installing the patch, since it doesn't if you use the manual method. In any case, I found that by editing the C:\Program Files\Mozilla Firefox\defaults\pref\bug307259.js file and commenting out the following line, the (No IDN) portion was removed and the (ax) portion was restored:
[tt]pref("general.useragent.productComment", "No IDN");[/tt]

Here are my notes, in case they're helpful to anyone:

09-10-2005 Downloaded 307259.xpi security patch to Setup\Mozilla Suite from link at:
https://addons.mozilla.org/messages/307259.html
and opened the xpi in WinZip. The bug307259.js file inside contains the following:
// rev version number so the patch is not offered again (bug307259)
pref("general.useragent.productComment", "No IDN");
pref("network.enableIDN", false);

I installed the patch from within Firefox 1.0.6... I noticed that it removed the (AX) from the UA
... so I edited the bug307259.js file by adding // in front of the follwoing line:
// pref("general.useragent.productComment", "No IDN");
...which restored the "(ax)" that is added to the UA from the activex.js file.

I then installed the XPI from within Mozilla Suite, by opening the saved XPI file. Since I only have one profile in DeerPark and SeaMonkey, I used the manual method there.

UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 (ax)

[J-M]

---clip---
Here are my notes, in case they're helpful to anyone:

09-10-2005 Downloaded 307259.xpi security patch to Setup\Mozilla Suite from link at:
https://addons.mozilla.org/messages/307259.html
and opened the xpi in WinZip. The bug307259.js file inside contains the following:
// rev version number so the patch is not offered again (bug307259)
pref("general.useragent.productComment", "No IDN");
pref("network.enableIDN", false);

Thanks for spreading your thorough notes. Yes, examining of .xpi package with WinZip is possible, many users tried this method to old http://ftp.mozilla.org/pub/mozilla.org/ ... lblock.xpi patch (see details at http://www.mozilla.org/security/shell.html ) as well.
It seems that the manual method (about:config) doesn't affect to user agent at all. In fact, this is what many users want. If she/he has skills to modify about:config or prefs.js file, there is skills enough to check the state of [tt]network.enableIDN[/tt] value too.

Edit: corrected a typo from 'IDN' J-M

UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fi-FI; rv:1.7.10) Gecko/20050717 (No IDN) Firefox/1.0.6

[J-M]

This manual method works in Netscape browser 8.0.3.3 too. This was confirmed with Windows 2000 Professional SP4.
Version NS7.2 was not tested due to several vulnerabilities fixed in newer version 8.

Restarting a browser was not needed when tested.

Instructions from the Mozilla.org Web site:

To manually change the browser configuration for Firefox or the Mozilla Suite, follow these instructions:

1. Type about:config into the address field and hit Enter.
2. In the Filter toolbar, type network.enableIDN.
3. Right click on the the network.enableIDN item and select toggle to change value to false.

Due to Firefox codebase Netscape Broeser 8.0.3.3 has the same [tt]network.enableIDN[/tt] value in use.

UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fi-FI; rv:1.7.10) Gecko/20050717 (No IDN) Firefox/1.0.6

[J-M]

How http://ftp.mozilla.org/pub/mozilla.org/ ... 307259.xpi affects to Netscape 8 user agent (check the UA string at posting). Very interesting

UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20050729 (No IDN) Netscape/8.0.3.3