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.
Re: (Score:1)
The parent comment should be modded up. It may not be "politically correct" from a leftist's perspective, but it is very relevant to this discussion.
For a lot of people, internationalization and localization really is more of a risk than a benefit.
I'm fluent in three languages, so I can appreciate the need for internationalization and localization for those who need it. Nobody is saying internationalization and localization shouldn't be supported. What we're saying is that it should be trivial to disable th
Re: (Score:2)
The parent comment should be modded up. It may not be "politically correct" from a leftist's perspective, but it is very relevant to this discussion.
Damn, it's completely obvious what a racist tirade against multicuturalism has to do with a zero day involving a Unicode exploit. The next time a cow shits, is that going to be taken as an example of the failings of multiculturalism?
I'm fluent in three languages, so I can appreciate the need for internationalization and localization for those who need it. Nobody is saying internationalization and localization shouldn't be supported. What we're saying is that it should be trivial to disable them when they aren't needed.
No, your parent CLEARLY states, and I quote, "Let's not do the same thing with browsers please.", in an implied response to supporting multiple languages. So not only is your position ridiculous for someone who supposedly knows three languages, a violation of your parent's claim
Re: (Score:2, Troll)
tries to accommodate every culture until its own gets lost in the noise
Which culture is it that's getting "lost in the noise"? The one we brought from Europe? The Native one we stepped on in the process? The African one we kidnapped to pick our cotton? The Chinese one that came to build our railroads? Or one of the hundreds of other cultures that have been coming in to our country since its inception?
We are a nation of immigrants. Unless you are full blood Native you don't have to go back more than a handful of generations to find a foreign parent.
The US somehow feels like it must apologize for even the most feeble effort at border patrols
This one I agree with y
Re: (Score:1)
Rome lasted for 1500 years or more
Ooh, I get to complain about the Slashdot post qua (Score:5, Informative)
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]
Re: (Score:2)
you should also complain about Slashdot subject le (Score:1)
Joke in subject, this is just filler.
59??? my chrome is 57 (Score:3)
My mac tells me it's running version 57.___ and it is up to date. So how long do I have to wait for 59?
Re: (Score:2)
My mac tells me it's running version 57.___ and it is up to date. So how long do I have to wait for 59?
Probably about 3 months. Beta is the next version, Dev is weekly build, Canary is nightly build. Stable releases are every 6 weeks.
https://www.chromium.org/getti... [chromium.org]
Re:So what's the fix? (Score:5, Interesting)
The article mentions an upcoming patch twice, but is silent on what it does.
Apparently, though not listed explicitly, they will display the unicode version (Ex: www.xn--80ak6aa92e.com instead of www..com) for these edge cases - though I'm not sure how they're detecting them.
IMO, it's all stupid mistakes and fixes because it's only an issue because they're trying to make it so "easy to use" and transparent for the dumbest of folks, while making it more and more complex to actually find the real info. For example, you used to be able to click the padlock icon next to the URL if it was an SSL domain, and that'd pop up security and cert info on Chrome. Now, you can't do that... you have to go into developer tools, then expand the tabs (security tab is often outside the window, because they moved the developer console to split the screen vertically instead of horizontally) to find security tab, then get the cert info there.
All domains should have a very very easy way to see both versions (the unicode/punycode version, and the localized version). Some options: ... or vice-versa: Eg. [lock icon] Secure | [www..com] https://www.xn--80ak6aa92e.com... [xn--80ak6aa92e.com]
* right click on the domain, include both in that menu
* mouse over the domain, show alt version in the status bar (bring back the status bar!)
* mouse over the domain, include alt version in mousever text
* include both on the location bar (one in parenthesis). Eg. [lock icon] Secure | [www.xn--80ak6aa92e.com] https://www./ [www.].com/
*
* add a little colored (red?) icon next to the name if punycode is in use. Mouseover on it would display info saying what that did. Clicking it would remove/add the decoding. IE: display the decoded localized characters by default; click the red dot to display the punycode; click again to go back to localized; set a preference from the right click menu on the red dot.
This isn't something that can be definitively solved programmaticly. It's still a case of tricking users. Just give the users the info they need so they can make a fair decision. The real DNS name is the fully encoded one (ex. xn--80ak6aa92e.com), not the one decoded from that, so please make that readily available to the user. IMO, displaying the localized text should be an added feature, not the primary display.
Re: (Score:2)
:-( I should have previewed that comment.
The two examples I provided should have been:
* include both on the location bar (one in parenthesis). Eg. [lock icon] Secure | [www.xn--80ak6aa92e.com] https://www.apple.com/ ... or vice-versa: Eg. [lock icon] Secure | [www.apple.com] https://www.xn--80ak6aa92e.com/
*
NOTE: in the above, the word "apple" would be the phishing version with the "l" replaced by a unicode character, or the "a" replaced by the greek "a", but slashdot doesn't like unicode, so I just entered
Firefox config switch (Score:5, Informative)
Re: (Score:1)
Re: (Score:2)
Yes, but will Firefox change/fix this soon?
Re: (Score:1)
Re: (Score:2)
That's dumb/stupid and won't help for those who don't know about this. Mozilla should just enable it by default with a patch or something.
multiple languages vs local language (Score:3)
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.
Re: (Score:2)
https://xn--pple-43d.comhttps/... [xn--pple-43d.comhttps]
Re: (Score:2)
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.
countries with non-traditional alphabets (Score:4, Insightful)
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.
Re: (Score:2)
They should've just said un-American.
Re: (Score:2)
Any alphabet I don't agree with is a Nazi alphabet.
Re: (Score:2)
URLs don't allow for ASCII. Try using a BEL character.
It is even inconsistent within the URL itself, with the domain names being case insensitive and having their own restrictions that aren't mirrored in the rest of the URL.
Re: (Score:1)
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".
Re: (Score:3)
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.
Re: (Score:2)
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.
TEN YEARS (Score:2)
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.
Actually Chrome 58 (Score:2)
The problem with .com really (Score:1)