A is available to demonstrate the exploit. There is currently no known workaround for Safari, and a potential fix Mozilla is questioned. Internet Explorer is not affected. Camino, however, appears to be vulnerable to the exploit.
Comments
...I'm moving over to Windows.
We can just view the source code of every page we visit and examine each link...err..um...nevermind.
Workaround for Mozilla-based products (Mozilla, Firefox, etc.):
Enter about:config in the address bar and click Go or hit Enter.
Scroll down to the network.enableIDN preference and double-click so the value is says "false".
The problem is that the setting will be ignored the next time Firefox is started and will have to be reset each time the browser is launched (even if the pref says "false").
As dumb as it may sound, this is NOT a true "security hole".
This is a pure abuse and disregard of the rules set for IDN handling, where top-level registrars are supposed to be as restrictive as possible in handing out IDN coded domain names. Of course, the ICANN turns a blind eye on the .com, .net and .org TLDs, opening up a can of worms in regard to phishing. Other TLDs are supposed to stick with their alphabet only to minimise problems, but some TLDs have not honoured this ( like Poland f.ex. - they would happily register "ibm·com.pl" - see a possible conflict with "ibm.com.pl" ? :)
That Firefox workaround is potentially disastrous, because it makes you THINK you've fixed it and you haven't! (I just confirmed that the setting is lost when you restart, even if it's still set to "false." That's a plain old BUG in Firefox.)
adamschneider: Agreed. Firefox forgets to read the preference at startup or something but shows its saved value in the about:config information. I'll have to re-double-click it each time I start up. Yes...it does suck.
i believe you can edit the file manually. everything edited with the "about:config" thing is not permanent. i cant remember where it is though right off hand. not at my mac at the moment. at work on a peecee.
Check the details at:
http://www.shmoo.com/idn/homograph.txt
Notice the timeline at the end of the document. They reported the problem to the vendors January 19, 2005, and published details of the exploit yesterday (February 6). Does security etiquette call for more time than that? I thought at least 60 days was the norm.
It's stored in the prefs.js file of your profile and it looks like it's stored correctly when altered by the about:config panel. It looks like the setting is not read at startup though.
OR
Network Headlines
Most Popular
Recent Reviews
Logitech Cube
The world of mice could often be described charitably as stagnant: it's an endless sea of ergonomic shapes that assume you're sitting ...
NewerTech and Targus USB Hubs For Gifts
A useful holiday present to resolve an ongoing frustration is a multi-port hub. Whether as a stocking stuffer, Chanukah present, or an ...
X-Rite ColorMunki Photo
Color calibration is the art of tweaking your monitor so that the colors represented on screen better match real life and your printer ...
Most Commented
Popular News
Fresh-Faced Recruit
Joined: Dec 2003
iCab is "safe" too.
iCab seems to be immune too. I get "Not Found" errors.