Slashdot Mirror


Shmoo Group Finds Exploit For non-IE Browsers

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.

111 of 621 comments (clear)

  1. Another IDN bug on Firefox by IO+ERROR · · Score: 5, Informative
    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 and set network.enableIDN to false.

    --
    How am I supposed to fit a pithy, relevant quote into 120 characters?
    1. Re:Another IDN bug on Firefox by drinkypoo · · Score: 5, Insightful

      I hope you do realize that on most computers, if the view source tool has ever been used, it was because the user hit it accidentally while trying to access another menu item or key combination...

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re:Another IDN bug on Firefox by Tetsugaku-San · · Score: 5, Insightful

      yeah, cos we ALL watch that stuff - and my monitor is at 320x200 so 3 pixels out is easy to spot . . . .

    3. Re:Another IDN bug on Firefox by vivin · · Score: 5, Informative

      Who says this is a Linux vulnerability? This is a browser vulnerability.

      Browsers != Linux.

      And it's not FUD - it is an actual problem. It sure tricked Firefox running on my windows machine.

      --
      Vivin Suresh Paliath
      http://vivin.net

      I like
    4. Re:Another IDN bug on Firefox by Troed · · Score: 4, Informative

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

    5. Re:Another IDN bug on Firefox by Anonymous Coward · · Score: 2, Informative

      1) It isn't a Linux vulnerability, it is an IDN phishing vulnerability that affects Firefox amongst other browsers
      2) Most people don't look at the source code!
      3) Hence it is a phishing vulnerability, i.e., masquerade to fool the average user
      4) It certainly isn't FUD when your non-geek relative loses a lot of money by one of these phishing attacks

    6. Re:Another IDN bug on Firefox by squiggleslash · · Score: 4, Informative
      Just tried it on Safari, and unfortunately none of the "bugs" that occur in Firefox that give the game away are present. Mouseover looks like Paypal. Connecting message shows nothing untoward. Renders as "www.paypal.com" in the regular font and location on the URL bar.

      I wonder if there's a quick and easy fix for this for Safari users, like there is for Firefox (about:config, network.enableIDN -> false.)

      --
      You are not alone. This is not normal. None of this is normal.
    7. Re:Another IDN bug on Firefox by NanoGator · · Score: 2, Insightful

      "This is just more FUD people"

      Ah, I get it. When it's about FireFox, it's FUD. When it's about Microsoft, it's just another reason to switch. Am I getting warm?

      --
      "Derp de derp."
    8. Re:Another IDN bug on Firefox by duvie · · Score: 3, Informative
      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?

    9. Re:Another IDN bug on Firefox by Digitalia · · Score: 2, Informative

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

      --
      Pax Digitalia
    10. Re:Another IDN bug on Firefox by finkployd · · Score: 5, Informative

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

      That is a great suggestion, except for the part where it does not work.

      Go ahead, make the change, then restart your browser. Now go look at about:config again. Yup, still set to false. Now go see if it the setting worked. It does not. So at least with Firefox 1.0 just took a bad situation and made it worse. Now people will think turning off this setting will actually accompolish something and protect them and it will not.

      Finkployd

    11. Re:Another IDN bug on Firefox by aWalrus · · Score: 4, Informative

      It worked for me (firefox in OS X). What it does is fix the lookup, not the display, so the links will still look as they did, but when you click on them it says "domain not found"

      --
      Overcaffeinated. Angry geeks.
    12. Re:Another IDN bug on Firefox by Aeiri · · Score: 2, Informative

      Ahh you stupid Slashdot parsing engine!

      Looks like "https://www.pypal.com/"

      That should be:
      Looks like "https://www.p[weirdchineselookingcharacterwithabo xaroundit]ypal.com/"

      ...and now I have to wait two minutes to post this and correct myself, great...

    13. Re:Another IDN bug on Firefox by AstroDrabb · · Score: 2, Informative
      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.
      --
      If Tyranny and Oppression come to this land,
      it will be in the guise of fighting a foreign enemy. -James Madison
    14. Re:Another IDN bug on Firefox by double-oh+three · · Score: 4, Informative

      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.

      --
      "For years, I struggled with reality... but I'm happy to say I finally won out over it." -- Elwood P. Dowd
    15. Re:Another IDN bug on Firefox by stuntpope · · Score: 4, Insightful

      Blame the stupid user because they don't read the source for every web page they go to? Come on. Are you, the highly intelligent informed user, going to start doing that now, even though there are no visual cues on the rendered page that something is amiss?

    16. Re:Another IDN bug on Firefox by Ced_Ex · · Score: 5, Insightful

      I suppose you understand how pharmaceuticals fully interact with your body? Or I suppose you fully understand every working part in your car?

      There are plenty of things people use that they have very little understanding of. They may know the interface of that device or system, but beyond that, it's all a black box to them. Browsers included.

      If you go by your statement of "if you don't understand it, don't use it", I'm sure there are plenty of things you can eliminate out of your own life as well.

      --
      Live forever, or die trying.
    17. Re:Another IDN bug on Firefox by drinkypoo · · Score: 2, Insightful

      Uh, guess what, most people don't understand what goes on inside an ATM. Almost no one (statistically) knows what goes on inside their engine, let alone their PCM. Most people don't even understand what all is involved in water getting to their house. Does that mean no one should use an ATM, drive a car, or turn on the faucet? Expecting users to know how HTML works before they surf the web is like expecting them to be an architect before they enter a building.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    18. Re:Another IDN bug on Firefox by AstroDrabb · · Score: 4, Informative
      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.

      --
      If Tyranny and Oppression come to this land,
      it will be in the guise of fighting a foreign enemy. -James Madison
    19. Re:Another IDN bug on Firefox by AstroDrabb · · Score: 3, Informative

      Restart you browser and then try again. I thought it was working until a restart of Firefox and it appears that the Firefox startup code doesn't properly set enableIDN based on your profile settings. As soon as you restart, the spoof works again. However, go into about:config and you will see that enableIDN is still set to false, so toggle it to true and then false again and the spoof won't work. Rinse, repeat.

      --
      If Tyranny and Oppression come to this land,
      it will be in the guise of fighting a foreign enemy. -James Madison
    20. Re:Another IDN bug on Firefox by strider44 · · Score: 3, Informative

      It's obvious without even looking for it on my 1280x1024 low-size font resolution. However most users will just think "that's odd" and not take any precautions.

    21. Re:Another IDN bug on Firefox by finkployd · · Score: 2, Informative

      Uh huh, try restarting your browser and going back. With mine (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0) I get the meeow paypal page even though about:config shows the setting is still set to false.

      Frightening to see this kind of bug in Firefox, I hope it is fixed soon.

      Finkployd

    22. Re:Another IDN bug on Firefox by Jane_Dozey · · Score: 2, Interesting

      Darn it! you're right :-(

      Then again...I have a nice little solution (quite by accident, in fact it's just due to me not bothering to sort my configuration out) anyway: any character sets not installed (all except the default) show up as a funny little square where the characters would normally be. I'd say that it's a pretty good give away when I've got http://www.p[]ypal.com (or there abouts) showing in the address bar...

      --
      Silly rabbit
    23. Re:Another IDN bug on Firefox by bunratty · · Score: 2, Informative

      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.

      --
      What a fool believes, he sees, no wise man has the power to reason away.
    24. Re:Another IDN bug on Firefox by callipygian-showsyst · · Score: 4, Funny
      I wonder if there's a quick and easy fix for this for Safari users,

      There is! Run I.E. in a VirtualPC window.

    25. Re:Another IDN bug on Firefox by Ulven · · Score: 2, Insightful

      Looking at the source would get a little tedious if one has to do it before clicking on every single link.

    26. Re:Another IDN bug on Firefox by bahamat · · Score: 4, Informative

      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.

    27. Re:Another IDN bug on Firefox by bunratty · · Score: 5, Informative

      This has been reported as bug 281377.

      --
      What a fool believes, he sees, no wise man has the power to reason away.
    28. Re:Another IDN bug on Firefox by networkBoy · · Score: 2, Informative

      It works _until_ you restart fool.
      -nB

      --
      whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
    29. Re:Another IDN bug on Firefox by QuietLagoon · · Score: 2, Interesting
      The only way I was able to tell on Opera (8.00, build 7401) that the site was a fake was to look at the console log of my http://www.privoxy.org/ web proxy.

      It showed:

      Feb 07 12:14:59 Privoxy(03720) Request: www.xn--pypal-4ve.com/
    30. Re:Another IDN bug on Firefox by sn0wflake · · Score: 3, Interesting

      You mean most users will never, ever, notice it. Even I as a Slashdot reader don't look at the URL constantly.
      Recon spyware coders will implement this in their programs now so it'll work in MSIE.

    31. Re:Another IDN bug on Firefox by AstroDrabb · · Score: 3, Interesting
      It was probably cached
      No, it wasn't cached. I cleared the cache in Firefox and also if you hold down shift and click Refresh, Firefox skips the cache and goes right to the server for the content. I think that the about:config interface correctly updated the enableIDN variable while the startup Firefox code doesn't look for the enableIDN settings in your user profile. To me that would explain why the settings take place immediately, yet fail to be set when you restart your browser.
      --
      If Tyranny and Oppression come to this land,
      it will be in the guise of fighting a foreign enemy. -James Madison
    32. Re:Another IDN bug on Firefox by metamatic · · Score: 2, Insightful

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

      --
      GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
  2. Are phishers going to bother with this, though? by The+I+Shing · · Score: 5, Interesting

    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?

    --
    You are in error. No-one is screaming. Thank you for your cooperation.
    1. Re:Are phishers going to bother with this, though? by AbbyNormal · · Score: 3, Insightful

      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.

      --
      Sig it.
    2. Re:Are phishers going to bother with this, though? by moon-monster · · Score: 4, Insightful

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

      --
      "Pokey, are you drunk on love?" "Yes. Also whiskey. But mostly love... and whiskey."
    3. Re:Are phishers going to bother with this, though? by double-oh+three · · Score: 4, Insightful

      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.

      --
      "For years, I struggled with reality... but I'm happy to say I finally won out over it." -- Elwood P. Dowd
    4. Re:Are phishers going to bother with this, though? by cortana · · Score: 2, Informative

      The problem is that the browsers are rendering the address correctly.

      The HTML entity а != U+1072. It corresponds to U+0430 CYRILLIC SMALL LETTER A, which it seems most fonts render almost exactly identical to U+0061 LATIN SMALL LETTER A.

      It appears the problem is in RFC3491 "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)" or RFC3292 "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)". As I understand it, one of the processes these RFCs describe involve a sanitisation process to be carried out on domain names, that fixes cases where an attacker is using odd unicode control characters to make one character appear like another.

      The problem is that these procedures overlooked U+0430 CYRILLIC SMALL LETTER A (and perhaps others?).

      So I suggest flagging the address field with a red tint when such characters are discovered as a work around, until the clever people who write RFCs come up with a good idea of how to proceed.

      More info on this blog, if you are interested.

  3. Canned Slashdot Response by bigtallmofo · · Score: 4, Funny

    Serves those Internet Explorer users right! They should immediately switch to ... uh, wait. Nevermind.

    --
    I'm a big tall mofo.
  4. So what? by Anonymous Coward · · Score: 5, Insightful

    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.

    1. Re:So what? by kimba · · Score: 4, Insightful

      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.

  5. Switch by Anonymous Coward · · Score: 5, Funny

    Damnit... now I'm switching back.

  6. IE also fails! (kinda) by grandmofftarkin · · Score: 4, Informative
    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 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.

    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.

  7. Firefox 1.0 by rubypossum · · Score: 4, Informative

    If you "View Source" for some weird reason the real address shows up in the title bar.

    --
    I have a theory that the truth is never told during the nine-to-five hours. - Hunter S. Thompson
  8. This isn't a newly discovered exploit. by tgd · · Score: 4, Insightful

    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.

    1. Re:This isn't a newly discovered exploit. by aug24 · · Score: 2, Informative

      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.

      --
      You're only jealous cos the little penguins are talking to me.
    2. Re:This isn't a newly discovered exploit. by mithras+the+prophet · · Score: 3, Informative
      Here's the earlier article: Spoofing URLs With Unicode. Summary:
      "Scientific American has an interesting article about how a pair of students at the Technion-Israel Institute of Technology 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, 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

      --
      four nine eighteen twenty-7 thirty-nine forty-7 fiftyeight sixty-nine seventy-9 eighty-8 one-hundred-and-nine one-twenty
  9. Opera won't fix it? by MoonFog · · Score: 5, Informative

    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.

    1. Re:Opera won't fix it? by Wudbaer · · Score: 4, Insightful

      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.

    2. Re:Opera won't fix it? by NanoGator · · Score: 2, Informative

      "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 was nice enough to put up a friendly message saying "Are ya sure you want to enter this particular domain?" (Kinda necessary, those @ symbols are useful.) Guess I just kinda expected more from Opera in this respect.

      --
      "Derp de derp."
    3. Re:Opera won't fix it? by TheIndividual · · Score: 5, Insightful

      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.

    4. Re:Opera won't fix it? by TheIndividual · · Score: 2, Interesting

      The nice thing is that you don't need to break or change the standard. It just shows that you should think a little about something before you implement it, even if it a widely used standard.
      In this case, why not introduce a warning popup if the domain name contains a unicode letter that looks like a normal ASCII letter.
      Effort? One lookup table of "bad" unicode letters and a small if-statement before opening a link...

    5. Re:Opera won't fix it? by cbr2702 · · Score: 2, Interesting
      Yup, except that the clear workaround does not fix the problem at all. The setting stays set to false in about:config after retstarting the browser, but in reality it goes back to enabling IDNs, and the paypal spoof referenced in this story still works.

      That's strange; I just tried it (in FF/1.0) and it remembered the setting and still had the site fail. Now the site still does render as "http://www.paypal.com/" in the status bar, but when I click on it I get a message saying "http://www.paypal.com/ was not found".

      This is one case where I like Linux's font support is not perfect. On the Mac the 'a' and the 'a' are indestinguishable, while here the latter is short and squat.

      --


      This post written under Gentoo-linux with an SCO IP license.
  10. I'm waiting the patch from MS by gustgr · · Score: 5, Funny

    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.

  11. Known for years.... by Chris_Jefferson · · Score: 4, Interesting

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

    --
    Combination - fun iPhone puzzling
  12. IDNs were a bad idea anyway by Anonymous Coward · · Score: 4, Interesting

    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.

  13. Stop obsessing over Microsoft, please. by Anonymous Coward · · Score: 2, Insightful

    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?

    1. Re:Stop obsessing over Microsoft, please. by strider44 · · Score: 4, Insightful

      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.

  14. network.enableIDN doesn't fix things by openSoar · · Score: 5, Informative

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

    1. Re:network.enableIDN doesn't fix things by finkployd · · Score: 4, Informative

      I was fully prepared to test this myself, find out you were either full of it (or a troll), and let /. know you were wrong.

      My plan was going perfectly, right up to the point where what you said turned out to be 100% correct :(

      Shame on Firefox for taking a bad situation and making it worse. If about:config reports that a security related setting is X when in fact it is Y, this is worse than not providing a fix at all. A false sense of security (from a browser that is supposed be better) is worse than being aware of the security problems and reacting accordingly.

      Finkployd

    2. Re:network.enableIDN doesn't fix things by sabit666 · · Score: 2, Insightful

      Totally untrue. What version of FF are you using?

  15. Not Lynx by OECD · · Score: 3, Interesting

    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)

    --
    One man's -1 Flamebait is another man's +5 Funny.
  16. ICANN is worried too by Peter_Pork · · Score: 5, Informative
    From ICANN's log:
    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 also.
    1. Re:ICANN is worried too by gowen · · Score: 3, Informative

      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.

      --
      Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
  17. Strength from weakness by XxtraLarGe · · Score: 2, Funny

    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!

    --
    Taking guns away from the 99% gives the 1% 100% of the power.
  18. Propaganda by AtariAmarok · · Score: 2, Informative

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

    --
    Don't blame Durga. I voted for Centauri.
  19. konqueror by j0nb0y · · Score: 2, Informative

    I've confirmed that konqueror is vulnerable. Anyone know how to disable this in konqueror?

    --
    If you had super powers, would you use them for good, or for awesome?
  20. Character apparances by remahl · · Score: 2, Insightful

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

  21. New Microsoft Security Mantra by IvanHo · · Score: 2, Funny

    Security through inutility

  22. Not all non-IE browsers by P-Nuts · · Score: 2, Insightful

    Links is unaffected - it goes to the real paypal site.

  23. Rebuttals by Jacco+de+Leeuw · · Score: 4, Funny
    • 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.
    :-)
    --
    -------
    Warning: Slashdot may contain traces of nuts.
  24. notepad by leuk_he · · Score: 5, Informative

    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!)

    1. Re:notepad by stuntpope · · Score: 2, Interesting

      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/

    2. Re:notepad by Myen · · Score: 3, Informative

      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.

    3. Re:notepad by AmberBlackCat · · Score: 2, Interesting
      blockquote>Trolls can have a couple of days fun on slashdot.

      I'd like to know your definition of 'troll'. In this case, it looks like Microsoft got something right and everybody else got it wrong. In fact, the fix for Firefox is to make it behave like IE (disable support for IDN). I'm guessing anybody who makes mention of this is a troll. I've only been modded down one time, and it was for saying something negative about Firefox even though it was completely true. I just recently got modded up for saying something negative about Microsoft. I would tell you what I think about that but I'd probably get modded down for that.

    4. Re:notepad by kerrle · · Score: 3, Informative
      Microsoft didn't "get something right", they just don't support the feature that this takes advantage of.

      IDN support is probably a good thing - we just need a way to show the user the difference between URLs if international characters are used.

    5. Re:notepad by AmberBlackCat · · Score: 3, Insightful

      Perhaps refraining from adding a feature until it can be done right could be considered "getting something right". And it would be easy to change "Microsoft got something right" to "Everybody except Microsoft got something wrong". But I would agree that in this case Microsoft didn't make their browser safer through actual thought. They just got lucky.

  25. Propaganda definition by AtariAmarok · · Score: 2, Informative
    "the systematic propagation of a doctrine or cause or of information reflecting the views and interests of those advocating such a doctrine or cause,"

    This can apply to any time anyone says anything. However, in practice, the word "propaganda" is only used when someone does not like being said. It is similar to "rhetoric" in this regard.

    --
    Don't blame Durga. I voted for Centauri.
  26. Visual cues could be more refined than that by FreeUser · · Score: 2, Interesting

    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 locale setting, so e.g. if my local is Germany, and cyrillic or french accent-grave or what have you characters are loaded, then display that character in bold, or in red, or what have you. Also, tint the background of the URL pink or something, so if the offending character is scrolled off the end of the URL field, the user still gets a visual clue that something is wrong.

    I'm sure there are other possibilities, like putting a little warning at the top whenever characters are in the URL that are strikingly similiar to characters in the default local OR standard ASCII, specifying what the character is and perhaps stating something like "http://spo0furl.com IS NOT THE SAME as http://spoofurl.com".

    --
    The Future of Human Evolution: Autonomy
  27. Talk About Asking For Trouble by sp3c1alK · · Score: 3, Insightful

    Comments like this worry me. We really have to be careful about letting our guard down just because Firefox is more secure. The whole point of the article is that the exploits DO exist.

    On one hand, we (the /. community) love to talk about how Firefox's market share is growing quickly but then minimize potential problems. So how is this problem 'less dangerous than some IE exploits'?

    Don't get me wrong, I'm all about Firefox, but we can't get lazy.

  28. Douglas Hofstadter: When an A is not an A by G4from128k · · Score: 5, Interesting

    This brings up the amusing problem of character recognition by human and non-human intelligences. Douglas Hofstadter discusses this issue in on seeing A's and seeing As.

    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.

    --
    Two wrongs don't make a right, but three lefts do.
  29. Re:Call me a flamer.... errr by wed128 · · Score: 2, Insightful

    Maybe one language is a little bit overkill. How about limiting it to one char. set?

  30. misleading commentary by jaiyen · · Score: 4, Insightful

    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.

    1. Re:misleading commentary by HolyCoitus · · Score: 2, Insightful

      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, if there is a spoofing exploit in css3 and Microsoft has not implemented it, is it the people who implemented it who are at fault or the people who created it? You're looking towards the wrong people for this problem I believe.

      --
      That's scary.
    2. Re:misleading commentary by runderwo · · Score: 2, Insightful

      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.

  31. Flag mixing character groups. by oneiros27 · · Score: 2, Interesting

    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 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 report if it's otherwise. Now, there are still problems with people not looking closely, and confusing 'resume.com' with 'résumé.com' or something similar, but you'll fix the problems with identical glyphs.

    The important thing to do is to not assume that ASCII is the only 'good' form, as that would make it rather english-centric (I'm not sure what other languages can map all of their characters into ASCII)

    --
    Build it, and they will come^Hplain.
  32. IDN pain in the but anyway by spectrokid · · Score: 5, Informative

    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.

    --

    10 ?"Hello World" life was simple then

  33. Re:IE and Firefox by Mattcelt · · Score: 2, Informative

    Spoofstick is a useful tool, too. I don't know if it protects against this particular attack, but it's good for the casual browser (i.e., mom/aunt gert/the cranky old guy down the street who always asks for computer help) to help protect against phishing.

  34. Re:Spin again by bersl2 · · Score: 2, Interesting

    No, you see, you are missing the point. The IDN system is flawed, not any particular browser.

    By making browsers an issue in the headline, there could be an immense amount of spin generated from this, where there didn't need to be any. Anybody who reads only the headline will thing an entirely different thing from someone who actually reads the comments and gets a perspective.

    To give an example of this that swings the other way, do you remember that announcement of the SP2 vulnerability in the stack overflow checking or something like that, that happened a week-or-so ago? And then Microsoft later said that no exploits have been found for it? That's the kind of thing that this headline can induce, because there is no perspective.

  35. Re:Bug or feature? by Dionysus · · Score: 3, Insightful

    Do tell me how am I going to have to type in a Chinese or Japanese domain name if I don't have keyboard layout (not to mention that I amy not even know *how* to input all these gliphs...).

    Do tell me when you became the world. Just because you personally likely won't use a feature doesn't mean it isn't useful for someone out there (what's the population of China and Japan combined?)

    --
    Je ne parle pas francais.
  36. A Possible Temporary Browser Solution by ehlertjd · · Score: 2, Insightful
    A temporary browser solution would be to detect links that use mixed unicode character sets, and keep the user from left-clicking to follow offending links and possibly even changing the mouse cursor. Then in a context menu, it should display the actual domain name.
    i.e.
    > Go To www.paypal.com (www.xn--pypal-4ve.com)
    > Help (explain why the link was disabled)
  37. Re:How to fix it in Firefox by NtroP · · Score: 2, Informative
    Yeah. Now quit Firefox and restart it.

    Doesn't work so well now, does it?

    This fact (IMHO) is more dangerous than not being able to make the setting at all. At least with Safari (et al) I know that I always have to be vigilant, instead of being lulled into a false sense of security.

    Clearly, Firefox has a major BUG in it. Fortunately, they seem to be pretty quick to fix these sort of things.

    --
    "terrorism" and "pedophilia" are the root passwords to the Constitution
  38. You're being too elitist by Tibor+the+Hun · · Score: 5, Funny

    I'm planning on taking an airplane flight in 7 years, and am already taking classes on aeronautics, history of flight, airplane engineering, and am enrolled in the technical school for airplane building and maintenancy.^H^H

    Uh-oh, looks like my "delete" key stopped working again. Must need another .5 ohm resistor, with a diode overlay. I'll do that as soon as I'm done casting the waterpump for my car.

    --
    If you don't know what AltaVista is (was), get off my lawn.
  39. Exploits by Novous · · Score: 3, Insightful

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

  40. Browsers ~!= Linux by willCode4Beer.com · · Score: 3, Insightful

    Although not a Linux, Windows, or Mac vulnerability, it could become one.

    If the site spoofed were a trusted site for firefox extensions they could get some code to execute on the box. They could package a root kit and take control of a Linux or Mac, or the Buffer overflow du jour to take control of a Windows machine. Granted the Linux would be the most difficult due the the large variation of distros (and each distro differs on opinion where file belong), compiler options, etc.

    For a truly secure OS, you should remove all applications and just run the OS in its pure state.

    --
    ----- If communism is a system where the government owns business, what do you call a system where business owns govern
  41. Firefox 1.0.1 by starwed · · Score: 2, Insightful

    Has anyone checked to see if this exploit is possible in the recent 1.0.1 builds? Presumably they contain security fixes... perhaps for this issue among whatever others exist.

  42. Bug in browser, or in Unicode? by Todd+Knarr · · Score: 2, Insightful

    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?

  43. Re:Why? by jdludlow · · Score: 2, Insightful

    Can anyone please tell me why people "hack" or "phish" or anything that is used for malicious activity? I'm not trying to start an argument, I seriously want to know why some people spend so much time trying to make others lives miserable.

    Money.

    Think for a minute why it would be beneficial to the bad guys to have people logging into their site with valid PayPal usernames and passwords.

  44. Unicode has already fixed this problem by fizbin · · Score: 4, Informative

    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/) 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.

    1. Re:Unicode has already fixed this problem by Have+Blue · · Score: 2, Interesting

      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.

    2. Re:Unicode has already fixed this problem by pdc · · Score: 3, Interesting

      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.

  45. The old MS spoofing quick-patch... by Curtman · · Score: 3, Funny

    Why don't you just start typing in your URIs from now on?

  46. Previous Slashdot article by rsteele19 · · Score: 2, Informative

    Slashdot has covered this problem before.

    --

    This sig is umop apisdn.

  47. Re:Typing foreign characters by greed · · Score: 2, Informative
    However on the subject of typing: the real problem is that typing foreign characters is insanely hard in every OS out there.

    This is strongly dependent on both the language and OS in question. For example, Japanese input methods work very well on US keyboards; you key in romaji, and the input method converts it to hirigana or katakana on the fly. When you hit space, a menu of kanji with the given reading is presented. Space again picks the first one, or cursor up/down before hitting space to pick another.

    This is apparently a quite common input method, as a Japanese friend who had never used a Mac told me how to use OS X's input method.

    The dead keys on Mac OS for Western European languages are also quite easy to get used to. (The AltGr thing on X11 I'm not so fond of.)

    But, of course, most Scandinavian users (referring to the grandparent post) will have Scandinavian keyboards, and they aren't entering foreign language sites, they're going to sites in their native languages.

  48. A few more browser tests (and IE *is* affected) by Reziac · · Score: 4, Informative

    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. :)

    --
    ~REZ~ #43301. Who'd fake being me anyway?
  49. Re:This is a really old spoof by aneroid · · Score: 2, Informative
    u mean this?
    <o:LastSaved>2002-01-31T17:32:00Z</o:LastSaved>
    (dated feb 2002)
  50. This is not a software bug... by microbrew_nj · · Score: 2, Interesting

    ... it's an authentication problem

    This problem is not a software bug. Sort of disabling the feature, I don't see a way of fixing the problem in the client software. I mean, I don't see a software patch (or even a standards modification) fixing the problem.

    What it is, is a problem exacerbated complexity. People speak different langauges around the world, often multiple langauges. That rules out an ASCII-centric solution. Even rewriting the standards wouldn't help; the problem boils down to protecting people from tmemselves, or at least human cognition flaws.

    Any solution would have to be a process solution. Specifically, the process determining that you are who you say you are. The current process for doing this is flawed for the average person. Your average person is just going to click through warnings which he or she doesn't understand.

  51. Its not a BUG! by maxkueng · · Score: 2, Informative

    As I see it, it is not a bug. International Domain Names are a standatd sind a while, already. The only problem is that some unicode characters look exactly like some UTF-8 characters and because of that, people can be "cheated".

    But who needs IDNs??
    In Mozilla/Firefox and maybe also in Thunderbird (if you download the about:config extension) IDNs can be disabled by using the about:config thingie.

    Open your Gecko based brwoser and type "about:config" (without the quotes) and hit return. Search for "network.enableIDN" (without the quotes) and set it to "false" (without the quotes).

    --
    Max

  52. Highlight, perhaps? by zcat_NZ · · Score: 2, Interesting

    When you go to a secure page Firefox highlights the URL yellow.

    When you go to a page with anything but ordinary ASCII characters perhaps it could highlight the URL blue, or red, or something...

    --
    455fe10422ca29c4933f95052b792ab2
  53. LiveHeaders on FF by MoFoQ · · Score: 2, Interesting

    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.

  54. browser doesn't need to run as root by willCode4Beer.com · · Score: 2, Informative

    Generally, these are tools (run as a regular user) to gain root access by exploiting things on the local box that are not accessible via the network. Espicially programs running with the suid bit (cron anyone?)
    If you run linux you will normally see many frequent security patches to protect *local* programs from just such exploits.

    --
    ----- If communism is a system where the government owns business, what do you call a system where business owns govern