Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security Internet Explorer Mozilla The Internet

Shmoo Group Finds Exploit For non-IE Browsers 621

Posted by Hemos from the even-mozilla-is-guilty dept.
shut_up_man writes "Saw this on Boing Boing: East coast hacker con Shmoocon ended today and they had a nasty browser exploit to show off... using International Domain Name (IDN) character support to display fake domain names in links and the address bar. Their examples use Paypal (with SSL too) and this looks very useful for phishing attacks. Interesting note that it works in every browser *except* IE (which makes this exploit a lot less dangerous in the end, I suppose)."v The reason IE isn't vulnerable is because it doesn't natively support IDN; with the right plug-in, it too is vulnerable.
This discussion has been archived. No new comments can be posted.

Shmoo Group Finds Exploit For non-IE Browsers More

Shmoo Group Finds Exploit For non-IE Browsers

Comments Filter:

  • Another IDN bug on Firefox (Score:5, Informative)

    by IO ERROR ( 128968 ) * <error.ioerror@us> on Monday February 07, 2005 @10:31AM (#11596597) Homepage Journal
    When trying this out on Firefox on Linux, I noticed that the URL in the address bar is rendered two or three pixels lower than normal. If you're paying close attention, this is easy to spot. Also, the "real" URL appears in the status bar while the spoofed page is being loaded, i.e. "Looking up www.xn--pypal-4ve.com..."

    To disable IDN as a workaround for this problem (on Gecko-based browsers): hit about:config [about] and set network.enableIDN to false.

    • Re:Another IDN bug on Firefox (Score:5, Insightful)

      by Tetsugaku-San ( 717792 ) on Monday February 07, 2005 @10:37AM (#11596679) Homepage
      yeah, cos we ALL watch that stuff - and my monitor is at 320x200 so 3 pixels out is easy to spot . . . .

    • Re:Another IDN bug on Firefox (Score:4, Informative)

      by Troed ( 102527 ) on Monday February 07, 2005 @10:39AM (#11596697) Homepage Journal
      Works 100% as advertised in Opera. No easy way to spot it's fake.

      On the other hand, this is nothing new. This was predicted a long time ago when debating on how to handle websites with charactersets incompatible with the ones used in Western countries ..

      • Re:Another IDN bug on Firefox (Score:5, Informative)

        by double-oh three ( 688874 ) on Monday February 07, 2005 @11:09AM (#11597051)
        And when this was presented at Shmoocon they mentioned that, IIRC they said that it was first thought up in 2001. Safari's fooled too, with the source code thing not apparently working. However if you try to save the page the international characters will disappear from the filename.
      • Yes, RISKS digest warned about this well over a year ago when IDN was being discussed.

        Obviously, everyone went ahead and implemented IDN anyway, without fixing the problem. I mean, this is the computer industry after all...

    • Comment removed (Score:4, Informative)

      by account_deleted ( 4530225 ) on Monday February 07, 2005 @10:41AM (#11596733)
      Comment removed based on user account deletion
    • One: the setting of enableIDN to false appears to have NO effect.

      Two: The only way to see that you are not at paypal (unless you notice the flash-by in the status bar) is to look at the certificate details. For the POC site, the certificate was issued to "www.xn--pypal-4ve.com"

      We all read those certs every time, neh?

      • One: the setting of enableIDN to false appears to have NO effect.
        Are you using Firefox 1.0? I set enableIDN to false and now if I click any of the spoof links, I instantly get a "www.paypal.com could not be found" alert.

        • Re:Another IDN bug on Firefox (Score:5, Informative)

          by AstroDrabb ( 534369 ) on Monday February 07, 2005 @11:12AM (#11597092)
          Hmm, I stand corrected. Setting enableIDN and then testing worked right away for me. Until I restarted my browser. About:config still shows enableIDN set to false, but the spoof works again. However, if I go back into about:config and reset enableIDN to false, it again stops the spoof.

          Maybe it is a problem in the Firefox startup code not setting enableIDN properly.

          • It still worked after restarting my browser using a recent trunk build of Mozilla on Windows XP. Try a recent trunk nightly build of Firefox and see if it works after restart.

          • Re:Another IDN bug on Firefox (Score:5, Informative)

            by bahamat ( 187909 ) on Monday February 07, 2005 @11:55AM (#11597604) Homepage
            It was probably cached, which does nothing to help anyone. Any user no matter how long they've been using computers is apt to think that disabling it will make a difference right away. I've been developing websites for close to 10 years, and browser cache is the biggest thorn in my side in that area.

            While you can view the certificate in Firefox, it takes a whopping 4 clicks to get the info that shows the page is bogus (double click the lock icon, click security tab, click view cert). The average user will never find it. Even the above average users will be thrown by the General tab which shows the spoofed URL as though it were the real one. If they don't actively hunt down all indications that a site may be spoofed, they're going to be fooled.

            What's worse, is that Safari doesn't even give the option to view certificates that it thinks are valid (not expired and signed by a valid root CA).

            Ouch.
    • That did not work for me. Upon disabling IDN, I went back and tried the link again. It was still spoofed.

    • notepad (Score:5, Informative)

      by leuk_he ( 194174 ) on Monday February 07, 2005 @10:48AM (#11596804) Homepage Journal
      If i copy /paste the link into notepad it just looks right And if i copuy /past it back to firefox i get the "spoofed" page back again.

      next:

      Trolls can have a couple of days fun on slashdot.

      And verisign van sell a lot of domains to phishers. (profit!)

      • Re:notepad (Score:3, Interesting)

        by stuntpope ( 19736 )
        Interesting... I copied the link from Firefox (Copy Link Location), pasted it into scite editor, and got http://www.p?ypal.com/. Pasting it back into Firefox gets me http://www.paypal.com/

        • A few more browser tests (and IE *is* affected) (Score:5, Informative)

          by Reziac ( 43301 ) * on Monday February 07, 2005 @01:52PM (#11599060) Homepage Journal
          Where "sees" means "displays it this way on the status line":

          Netscape 3.04 sees http://www.p?ypal.com/ -- looks the same in docsource

          OffByOne 3.4a sees http://www.p0ypal.com/ -- looks the same in docsource

          K-Meleon 0.9 sees http://www.p?ypal.com/ -- looks like http://www.pypal.com/ in docsource

          IE 5.00.2314.1003 (yes, minor builds can make a *big* difference in how IE displays stuff) sees it as http://www.paypal.com/, but the "a" is about half normal size (this is at 1024x768). Docsource as IE feeds it to notepad looks like http://www.pypal.com/

          Mozilla 1.5 sees it exactly the same as IE5.00 (above), including docsource

          AOLpress (HTML editor with built-in browser) sees it exactly the same as OffByOne (above), including docsource

          Netscape 4.50 sees http://www.p?ypal.com/ but displays http://www.pypal.com/ in docsource

          Firebird 0.7 sees it exactly the same as Moz 1.5 and IE5.00 (above), including docsource

          And Mosaic 0.9 can't figure out WHAT to do with the page and wants to save it to disk.

          At this point, I ran out of installed browsers. :)

      • Re:notepad (Score:3, Informative)

        by Myen ( 734499 )
        Probably depends on Windows version - on 2k/XP at least, Notepad is a Unicode app and can handle non-ASCII characters; not the case in 9x.

        Use the command prompt; by default that wouldn't be able to handle the right characters and should show up as '?'. Actually, I think the default raster font for that just doesn't have the character.

    • Comment removed (Score:5, Informative)

      by account_deleted ( 4530225 ) on Monday February 07, 2005 @10:52AM (#11596841)
      Comment removed based on user account deletion

  • Are phishers going to bother with this, though? (Score:5, Interesting)

    by The I Shing ( 700142 ) * on Monday February 07, 2005 @10:31AM (#11596602) Journal
    I'm surprised to hear that Microsoft's refusal to adopt international standards in their browser actually thwarts a potential phishing attack rather than aiding it. If the problem can't be fixed in the browsers, maybe email clients and websites can find some way of decoding, detecting, and disabling such links. Are phishers going to bother trying to use this exploit if it works on less than 10% of their potential victims?

    • Re:Are phishers going to bother with this, though? (Score:4, Insightful)

      by AbbyNormal ( 216235 ) on Monday February 07, 2005 @10:41AM (#11596732) Homepage
      Cmon. We are all touting Firefox to be the next "Greatest" thing since sliced bread. I have it installed on most of my family's machines. What now when M$ turns this around and says: "See? Only MS prevented this flaw because of our proprietary tested..bla blah".

      All it takes is 1% of the 10 percent.

    • Re:Are phishers going to bother with this, though? (Score:4, Insightful)

      by moon-monster ( 712361 ) on Monday February 07, 2005 @10:43AM (#11596750) Homepage Journal

      > Are phishers going to bother trying to use this exploit if it works on less than 10% of their potential victims?

      They sure are. Think about how many people actually respond to spam messages. It's probably much smaller than 0.01%, but it's still economical enough for the to send out the messages anyway. I'd be fairly confident that the same holds true for phishers, too.

    • Re:Are phishers going to bother with this, though? (Score:5, Insightful)

      by double-oh three ( 688874 ) on Monday February 07, 2005 @11:20AM (#11597187)
      The fix is simple for this(for firefox at least), just have a little bar appear at top(like the popup one) and have a message saying that there are international characters in the address. Have a button with a link to the non-international charactered page. There's no reason to kill international character support, just make it so that the user is warned.

  • Canned Slashdot Response (Score:5, Funny)

    by bigtallmofo ( 695287 ) on Monday February 07, 2005 @10:32AM (#11596606)
    Serves those Internet Explorer users right! They should immediately switch to ... uh, wait. Nevermind.

  • So what? (Score:5, Insightful)

    by Anonymous Coward on Monday February 07, 2005 @10:32AM (#11596621)
    This isn't per-se a browser fault, it is more of a flaw in the IDN system.

    Atleast, we can bash FF instead of IE now.

    • Re:So what? (Score:5, Insightful)

      by kimba ( 12893 ) on Monday February 07, 2005 @10:45AM (#11596776)
      It isn't even that. It is a fundamental side-effect with the the notion of internationalization, and the fact cyrillic and latin (and others) share the same letters. More specifically you may consider it can be pinned on the way Unicode enumerates characters (by giving different code points to letters rendered the same).

      It isn't a fault of the browser or IDNs.

  • Switch (Score:5, Funny)

    by Anonymous Coward on Monday February 07, 2005 @10:33AM (#11596626)
    Damnit... now I'm switching back.

  • IE also fails! (kinda) (Score:5, Informative)

    by grandmofftarkin ( 49366 ) * <3b16-ihd3@xemaps.com> on Monday February 07, 2005 @10:33AM (#11596627)
    The first thing I did was fire up IE (a rare occurrence) and test this. IE also failed (for me). Then I remembered that I have the i-Nav plug-in [idnnow.com] installed. Granted, this isn't actually a fault of IE then but rather the plugin. Though it should be noted that IE is only spared because (in it's default configuration, i.e. without the plugin) it doesn't support standards. In this case that standard is Punycode [wikipedia.org].

    This would actually appear to be a flaw in the Punycode standard rather than the browsers themselves, given that all IDN (internationalized domain name) aware browsers similarly fail.

    Looks like someone may have to fix Punycode. Then we can update the browsers. In the mean time perhaps Opera, Firefox, etc. can given some kind of visual notification when Punycode is used, in the same way the URL turns yellow when a secure URL is entered in Firefox.

    • There is already a fix for this IDN problem in the unicode spec, if people would just use it:

      Before resolving, all domain names should be normalized according to normalization form KC. (see http://www.unicode.org/unicode/reports/tr15/ [unicode.org]) Once that's done, anything that looks like an "a" really will be an "a", and not something that looks identical in Cyrillic.

      That simple (SIMPLE!) step would avoid this problem, almost completely. There'd still be an issue with people using "paypál" instead of "paypal", but at least then the user has some vague chance of seeing the difference in the URL in the browser window.

      It would also be good if responsible registrars refused to accept domain registrations for domains not normalized according to NFKC, but asking companies to refuse business simply because someone else would get hurt is probably not going to be effective.
      • Wouldn't it be possible to enforce registrar standards compliance by having all DNS servers reject noncompliant records, not just the registrar's signup process? If a noncompliant record was not accessible to a large chunk of the net, that would be a strong incentive to make sure legitimate names are compliant and make this type of scam less effective.

      • Re:Unicode has already fixed this problem (Score:4, Interesting)

        by pdc ( 19855 ) * on Monday February 07, 2005 @01:29PM (#11598761) Homepage
        I don't claim to be a Unicode expert, but I don't think that normalization form KC will convert U+0430 to 'a', because the Latin small letter A is not its compatability decomposition.

        On the other hand, it would prevent spoofing of Greek names using mu and capital omega, or capital A with ring above, or ff ligatures, since there are characters that have them as compatibility decompositions.

  • Firefox 1.0 (Score:4, Informative)

    by rubypossum ( 693765 ) * on Monday February 07, 2005 @10:34AM (#11596642)
    If you "View Source" for some weird reason the real address shows up in the title bar.

  • This isn't a newly discovered exploit. (Score:5, Insightful)

    by tgd ( 2822 ) on Monday February 07, 2005 @10:35AM (#11596650)
    I can remember discussions about it years ago. I'd bet there may even be a /. article about it, although its not really worth searching to see.

    This was a big part of the critisism around supporting larger character sets in domain names.
    • You're right - the example from a couple of years ago was using www.microsoft.com but with the Os in microsoft being a russian character that is drawn identically.

      I can't be arsed to search for it either.

      Justin.

    • Re:This isn't a newly discovered exploit. (Score:4, Informative)

      by mithras the prophet ( 579978 ) on Monday February 07, 2005 @11:46AM (#11597486) Homepage Journal
      Here's the earlier article: Spoofing URLs With Unicode [slashdot.org]. Summary:
      "Scientific American has an interesting article [sciam.com] about how a pair of students at the Technion-Israel Institute of Technology [technion.ac.il] registered "microsoft.com" with Verisign, using the Russian Cyrillic letters "c" and "o". Even though it is a completely different domain, the two display identically (the article uses the term "homograph"). The work was done for a paper in the Communications of the ACM (the paper itself is not online). The article characterizes attacks using this spoof as "scary, if not entirely probable," assuming that a hacker would have to first take over a page at another site. I disagree: sending out a mail message with the URL waiting to be clicked ("Bill Gates will send you ten dollars!") is just one alternate technique. While security problems with Unicode have been noted here before [slashdot.org], this might be a new twist."

      Incidentally, it seems that Slashdot's ASCII-only URL reporting system successfully deflects such spoofing here: Go to paypal.com [www.p]

  • Opera won't fix it? (Score:5, Informative)

    by MoonFog ( 586818 ) on Monday February 07, 2005 @10:35AM (#11596655)
    From the text:
    VI. Vendor Responses

    Verisign: No response yet.
    Apple: No response yet.
    Opera: They believe they have correctly implemented IDN, and will not be making any changes.
    Mozilla: Working on finding a good long-term solution; provided clear workaround for disabling IDN.
    So, Opera won't fix it? They have a proof of concept, and Opera believe their implementation is correct? Maybe, but they still need to provide an update, and something tells me they will .. eventually.

    • Re:Opera won't fix it? (Score:5, Insightful)

      by Wudbaer ( 48473 ) on Monday February 07, 2005 @10:38AM (#11596691) Homepage
      The problem is not their implementation, which is likely correct. The problem is that the standard is "wrong" is this respect.

      So it will be quite difficult to fix this without breaking and/or changing the standard.
      • You're probably correct, but that doesn't help the fact that their browser is vulnerable to this exploit. As the article summary states, they do not have an option to turn the use of IDN off.
    • "So, Opera won't fix it? They have a proof of concept, and Opera believe their implementation is correct? Maybe, but they still need to provide an update, and something tells me they will .. eventually."

      In case anybody's curious, Opera's broken, too.

      I'm really kinda saddened by this. There was an exploit a year or two ago that worked in a similar way. It involved using an @ symbol in the header to disguise the true domain. At the time, Mozilla and IE were absolutely broken in that respect, but Opera

    • Re:Opera won't fix it? (Score:5, Insightful)

      by TheIndividual ( 812531 ) on Monday February 07, 2005 @10:44AM (#11596763) Homepage Journal
      Well it isn't really a bug. Their implementation is correct it just suffers a flaw that IDN introduced. So from a technical point of view, the browser does what it is supposed to do. However it would be nice to see them implement some kind of protection against unicode letters looking like ASCII-letters. A warning popup or colour coding of those letter maybe.

  • I'm waiting the patch from MS (Score:5, Funny)

    by gustgr ( 695173 ) <(gustgr) (at) (gmail.com)> on Monday February 07, 2005 @10:35AM (#11596658)
    Ok, it doesn't work in IE... so when the patch will be released? I mean... it is IE, the exploits HAVE to work. Microsoft should be worried, they are not doing their job properly.

  • Known for years.... (Score:5, Interesting)

    by Chris_Jefferson ( 581445 ) on Monday February 07, 2005 @10:35AM (#11596659) Homepage
    Seriously, it's been known for years that adding international character sets was going to cause the problem of multiple identical (or almost identical) characters.

    On the other hand, no-one really seems sure of the best way to fix it... One option is obviously to mark somehow when non-ASCII characters are used, but while this will help the people who only want ASCII URLs, it will still leave the problem for everyone who wants to use this extended system, making it effectively useless....

    • On the other hand, no-one really seems sure of the best way to fix it... One option is obviously to mark somehow when non-ASCII characters are used, but while this will help the people who only want ASCII URLs, it will still leave the problem for everyone who wants to use this extended system, making it effectively useless....

      I think you're on the right track here.

      Perhaps the best approach is to use a different font/different color for particular ranges of characters, or characters outside of one's local
    • It's intentional that there are multiple glyphs that look the same, but represent different characters in Unicode. (for sorting order, spell checking, etc.)

      So you just need to work off of that strength, and flag when someone's mixed any two groups of characters. (I'm not sure what the official Unicode name is for them ... the different sets assigned to each language [unicode.org] or function).

      Anyway, you start with the assumption that a domain name is going to contain only characters from one of those groups, and you

  • IDNs were a bad idea anyway (Score:4, Interesting)

    by Anonymous Coward on Monday February 07, 2005 @10:36AM (#11596663)
    Except when implemented in their own country code namespace of course.

    There are so many characters that look alike, that it is trivial to register a domain name that will look the same as another one. Typically the different character would only be recognised by a native that used that character, although using it alongside normal English characters would probably throw them off as well.

    Solution? Maybe an "IDN" icon in the URL bar, or a warning if an IDN uses a mixture of normal English characters with some foreign characters in an IDN.

  • Stop obsessing over Microsoft, please. (Score:2, Insightful)

    by Anonymous Coward
    The reason IE isn't vulnerable is because it doesn't natively support IDN; with the right plug-in, it too is vulnerable.

    IE wasn't relevant to this article, yet you found a way to wedge it in and smear it regardless.

    The browsers the exploit WAS found for weren't even mentioned by name, yet IE was.

    How is this anything except nasty propaganda?

    • Propaganda (Score:2, Informative)

      by AtariAmarok ( 451306 )
      "Propaganda" being anything someone says that you do not like. Mentioning IE is quite relevant. My first thought on reading such a thing is its status in regards to MSIE. Also, in case you have not heard before, MSIE has a reputation for being subject to such exploits in the past.

    • Re:Stop obsessing over Microsoft, please. (Score:5, Insightful)

      by strider44 ( 650833 ) on Monday February 07, 2005 @11:25AM (#11597250)
      IE wasn't relevant to this article, yet you found a way to wedge it in and smear it regardless.

      What about to the people who have the plugin for IDN? This is a place for geeks, and there are bound to be people that have that sort of plugin. Saying IE isn't affected is pretty much false in that light.

  • network.enableIDN doesn't fix things (Score:5, Informative)

    by openSoar ( 89599 ) on Monday February 07, 2005 @10:36AM (#11596671)
    The 'fix' they mention (setting network.enableIDN to false via about:config) only works until you restart the browser - when you reopen the browser, things are back to the same even though the setting is still false..

  • Not Lynx (Score:4, Interesting)

    by OECD ( 639690 ) on Monday February 07, 2005 @10:37AM (#11596678) Journal

    It doesn't seem to work with Lynx, either. The URLs are obviously different from what they're supposed to be, and they don't point to any site at all.

    Lynx does try the URL, though, so it may be possible to set up another domain to catch it, but the URL would still be obviously wrong (something like p%a%y%p%a%l.com)

  • This is defeated as well. Normally, you see the real domain name in Spoofstick under Firefox on Windows. As another poster stated, you do indeed briefly see the real URL in the status bar.

  • ICANN is worried too (Score:5, Informative)

    by Peter_Pork ( 627313 ) on Monday February 07, 2005 @10:38AM (#11596690)
    From ICANN's log [icann.org]:
    There are many technical problems with this change. It essentially undermines IDNA, which is now on standards track, by adding a level of guessing to the DNS that IDNA is explicitly designed to avoid. Further, it makes it appear that IDNs are only useful in domain names for web sites (and only for sites in .com and .net), and only at the second level. VGRS has said that their plug-in will not work with most of the ccTLDs, for example.

    For example, if you enter .com in Internet Explorer for Windows, where "" is the single hex octet 0xE5, you see the screen shown in the attached file called "[lynn-message-to-iab-06jan03-]e5.tif". (Sorry about the TIFF image, but it's the only reliable format for PC screen dumps.) As you can see, VGRS makes wild guesses about what the user wanted, some of which are very clearly impossible. Worse yet, they do not include all of the legal guesses that they could have made. And, just to make it completely confusing to the user, not all of the choices work.

    The DNS is not supposed to be a best-guess service, yet VGRS has turned .com and .net into this just before IDNA is to be an RFC. VGRS should not be allowed, through its monopoly on the .com and .net gTLDs, to destroy the coherence of the DNS for its own short-term profit. ICANN should demand that VGRS immediately stop giving incorrect answers to any query in .com and .net, and should instead follow the IETF standards. If VGRS refuses, ICANN should re-delegate the .com and .net zones to registries that are more willing to follow the DNS standards.
    See this [computerworld.com] also.

    • Re:ICANN is worried too (Score:3, Informative)

      by gowen ( 141411 )
      Neither of those are about this concern (homographs between Cyrillic and Latin alphabets). That's a concern about Verisign using non-IDN methods to do DNS-lookups, and (like the late, unlamented SiteFinder) doing fuzzy matches in the case of unrecognised UTF domain names.

  • Strength from weakness (Score:3, Funny)

    by XxtraLarGe ( 551297 ) on Monday February 07, 2005 @10:38AM (#11596692) Journal
    The reason IE isn't vulnerable is because it doesn't natively support IDN; with the right plug-in, it too is vulnerable.

    IE is safer because it doesn't support a feature? Don't worry, I'm sure the plug-in will be installed with the next security update!

  • konqueror (Score:3, Informative)

    by j0nb0y ( 107699 ) <(jonboy300) (at) (yahoo.com)> on Monday February 07, 2005 @10:39AM (#11596703) Homepage
    I've confirmed that konqueror is vulnerable. Anyone know how to disable this in konqueror?

  • Character apparances (Score:3, Insightful)

    by remahl ( 698283 ) on Monday February 07, 2005 @10:40AM (#11596710)

    I thought this was a well-known attack -- using Unicode characters that look like latin but aren't. As more and more web sites start accepting unicode in user names without policing, I think we'll find more interesting applications for this type of attack.

    This is not that different from "spoofing" using this address:

    http://www.paypaI.com [paypai.com] I.e. replacing the lower-case L with an upper-case i. (except that paypai.com appens to be taken already, by an annoying site that maximizes the browser window no less.)

  • Security through inutility

  • Not all non-IE browsers (Score:3, Insightful)

    by P-Nuts ( 592605 ) on Monday February 07, 2005 @10:42AM (#11596743)
    Links is unaffected - it goes to the real paypal site.

  • Rebuttals (Score:5, Funny)

    by Jacco de Leeuw ( 4646 ) on Monday February 07, 2005 @10:43AM (#11596759) Homepage
    • Oh, come on! Even I saw the differences between those two a's!
    • Move your pointer to the padlock and you'll see that the certificate was signed by the UserTrust Network instead of the usual suspects (Verisign, Thawte etc.).
    • Certificates from the UserTrust Network are not to be trusted anyway. They don't check anything and you cannot trace back the owner of the domain.
    • CAs should rejects CSRs with these characters.
    • The CA should revoke those certificates. (You did enable OCSP, didn't you?)
    • It doesn't work with links/lynx.
    :-)

  • Douglas Hofstadter: When an A is not an A (Score:5, Interesting)

    by G4from128k ( 686170 ) on Monday February 07, 2005 @10:55AM (#11596876)
    This brings up the amusing problem of character recognition by human and non-human intelligences. Douglas Hofstadter [indiana.edu] discusses this issue in on seeing A's and seeing As. [stanford.edu]

    In the case of this exploit, a deep flaw in IDN and computer fonts means that character #1072 is rendered typographically as an "a". The irony is that this is one of the few cases in which a computer can readily tell the difference between "a" and #1072 and a person cannot. The only solution would be rules that prohibit isomorphic characters in typefaces or a in-browser warning system that analyses the potential for ambiguity and alerts the user.

  • misleading commentary (Score:4, Insightful)

    by jaiyen ( 821972 ) on Monday February 07, 2005 @11:02AM (#11596953)
    This will probably lose me major karma for going against groupthink, but the statement that "The reason IE isn't vulnerable is because it doesn't natively support IDN; with the right plug-in, it too is vulnerable." does seem ridiculously biased.

    While it may be technically true, it's like suggesting Firefox is susceptible to IE's infamous ActiveX vulnerabilities, just because there's an ActiveX plugin for Firefox too. Everyone is quick to jump on MS when there's new IE exploits, but we've got to accept that this seems to be one they got right. Making excuses about plugins doesn't really change that.
    • A standard for accessing international websites using special characters is not comparable to a programming language that is horribly designed. Are you suggesting that dragging your feet for five years before implementing a standard some feel is required is proper security?

      The issue at hand here is that Firefox did not create IDN. Microsoft _did_ create ActiveX. The blame falls in both cases on Microsoft for being slow to implement something and absolutely ignorant to create ActiveX.

      In other words, i
    • This is a vulnerability in a standard, not in any particular browser. If IE implemented this standard (which it does, with a plugin), it would suffer similarly.

  • IDN pain in the but anyway (Score:5, Informative)

    by spectrokid ( 660550 ) on Monday February 07, 2005 @11:04AM (#11596982) Homepage
    Here in Scandinavia, the letters Å,Æ,Ø, are actually quite new. It is acceptable to spell them as AA, AE and OE respectively on non-scandinavian keyboards. With IDN adresses now becomming available, you constantly have to remember which spelling is used on which website. It would be a hell of a lot more practical if only the 26 alphabeth was used and software would automatically expand ingeniøren.dk to ingenioeren.dk. This way you could use whatever you want. And websites will not be too happy about using special characters, because it makes them almost impossible to reach on non-scandinavian computers.

  • Exploits (Score:3, Insightful)

    by Novous ( 844236 ) on Monday February 07, 2005 @11:47AM (#11597504)
    >The reason IE isn't vulnerable is because it doesn't natively support IDN; with the right plug-in, it too is vulnerable.

    Well, if we're going to disregard them on those grounds, we might as well disregard ActiveX exploits too (since FireFox doesn't support it). An exploit is an exploit. Don't play the game of justification.

    p.s. I use Firefox.

  • Bug in browser, or in Unicode? (Score:3, Insightful)

    by Todd Knarr ( 15451 ) on Monday February 07, 2005 @11:51AM (#11597559) Homepage

    This seems to be more of a bug in Unicode than in the browsers. Unicode has defined multiple character codes as having the exact same glyph. I thought we'd already run into this in Unicode with multiple long representations of the same character, decided it was a bad thing and corrected it by making any representation longer than the shortest illegal. Shouldn't we do the same thing here, and simply make it illegal to have multiple character codes appearing as the same glyph?

  • Previous Slashdot article (Score:3, Informative)

    by rsteele19 ( 150541 ) on Monday February 07, 2005 @12:59PM (#11598370) Homepage
    Slashdot has covered this problem before [slashdot.org].

  • LiveHeaders on FF (Score:3, Interesting)

    by MoFoQ ( 584566 ) on Monday February 07, 2005 @03:10PM (#11599963)
    LiveHeaders on FF correctly reports that the HOST is not paypal.com

    Looks like I'll have to use that to double check now. Still safer that IE.

Slashdot Top Deals

The truth of a proposition has nothing to do with its credibility. And vice versa.

Close