Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Google Chrome Privacy Security The Internet

Chrome 59 To Address Punycode Phishing Attack 69

Google says it will be rolling out a patch to Chrome in v59 to address a decade-old unicode vulnerability called Punycode that allowed attackers to fool people into clicking on compromised links. Engadget adds: Thanks to something called Punycode, phishers are able to register bogus domains that look identical to a real website. Take this proof-of-concept from software engineer Xudong Zheng, where apple.com won't take you to a store selling Macs, iPhones and iPads. The real website is actually https://www.xn--80ak6aa92e [dot] com. The xn-- prefix tells browsers like Chrome that the domain uses ASCII compatible encoding. It allows companies and individuals from countries with non-traditional alphabets to register a domain that contains A-Z characters but renders in their local language. The issue was first reported to Google and Mozilla on January 20th and Google has issued a fix in Chrome 59. It's currently live in the Canary (advance beta release) but the search giant will likely make it available to all Chrome users soon.
This discussion has been archived. No new comments can be posted.

Chrome 59 To Address Punycode Phishing Attack

Comments Filter:
  • by Kiwikwi ( 2734467 ) on Monday April 17, 2017 @10:46AM (#54248587)

    Horrible summary... Punycode [wikipedia.org] is an encoding, not a vulnerability. The vulnerability is a variant of the well-known homograph attack.

    The original source explains it better: https://www.xudongz.com/blog/2... [xudongz.com]

  • by Jason69 ( 661789 ) on Monday April 17, 2017 @11:05AM (#54248687)
    In Firefox / about:config set: network.IDN_show_punycode;true
  • by MSG ( 12810 ) on Monday April 17, 2017 @11:40AM (#54248977)

    The original post notes that "In Chrome and Firefox, the Unicode form will be hidden if a domain label contains characters from multiple different languages."

    It seems to me that a better solution would be to simply display the unicode version only if it contains only characters in the language that the browser is running in (such as the LANG setting on POSIX systems)... especially if the purpose of punycode is to allow domains that "render in their local language."

    Admittedly, that fails to protect Cyrillic systems from the domain used as an example, but it does limit the scope of the problem.

    • by wbr1 ( 2538558 )
      How about displaying both ie:

      https://xn--pple-43d.comhttps/... [xn--pple-43d.comhttps]

      • If this is a real security issue, displaying both domains sounds like a non-elegant but working solution. The punicode domain should be displayed where the domain name usually is, and decoded version in the right half of the address bar. Ditto for mouse holdover pop-ups.

        IE's approach seems to be to silently block these URLs from opening, which is also bad.

  • by remi2402 ( 816874 ) on Monday April 17, 2017 @11:44AM (#54249031)

    countries with non-traditional alphabets

    Say what now? Non-traditional? How about simply "languages with non-latin scripts"! And even that description isn't completely accurate as there are plenty of languages written using variants of latin scripts that could benefit from punycode (Spanish, French, German, Scandinavian languages, quite a few Slavic languages, Vietnamese, and I'm probably forgetting a lot).

    I usually don't care about this sort of things but this time I'll bite: there are about 6.5+ billion people on this planet that use "non-traditional alphabets". It's about time whoever wrote the FA at Engadget learns a little bit about the rest of the world.

    • They should've just said un-American.

    • by Anonymous Coward

      Say what now? Non-traditional?

      What it meant to say was "non-traditional in the context of the internet". The internet started out as an ASCII7 medium (not even ASCII8!). Then other encodings came along, but until very recently you couldn't use things like unicode in domain names at all.

      So in the context being discussed - domain names - anything beyond UTF8 is "non traditional".

    • While you are right, i believe the sentiment of the statement is to point out that almost all websites use a restricted ASCII alphabet. And i say this as a spanish speaker.

      • almost all websites use a restricted ASCII alphabet

        Almost all english websites maybe. There's a huge frigging world out there in unicode if you dared to look. It just doesn't show up neatly in a Google search result resulting in observer bias.

  • An easy phishing exploit, left untouched for ten years.

    Does Google not bother hiring black hats to check for this kind of stuff? It's obvious their white-hats have no BOFH credentials.

  • It will get a fix in Chrome 59, not 59. There's already a fix in Chrome Canary 59. But the stable branch will get it by the end of the month.
  • IMHO it's the problem with .com domain policy – no top level domain should allow the use of different scripts/alphabets. Countries using cyrillic don't allow using cyrillic IDN domains under .ru and .bg for example, there are . and . for that. In the same way .com should allow ASCII only. Yes, there is theoretically homographs problem with top level domains as well, but it is realistically controllable.

Trap full -- please empty.

Working...