Live data from Hacker News

Can we believe our eyes? Misleading people with Unicode.

blogs.technet.com

41–50 of 128 posts

Re: Can we believe our eyes? Misleading people with Unicode.

#41
Somewhat related to this is the ability to change 'l" and "I" around when they both look the same, basically a straight line.

This was very common in Yahoo Chat Rooms when folks would pretend to be someone else by registering their name with the opposite of what they had (assuming it had an "i" or "l" in it).

They would then take a screen shot of their font and copy that exactly so they could appear to be the other person. I'll let you imagine the chaos that could occur because of this!

Re: Can we believe our eyes? Misleading people with Unicode.

#42
post #5
post #3

I'm pretty shocked that I have never heard of the RLO unicode character before this article. Let's see if it works: ppa.emorhCelgooG => ‮ppa.emorhCelgooG

Whoa. Check out you did to the markup of this page. http://d.pr/HKSQ

The HTML standard specifies that changes in text direction are bounded to the block they occur in: http://www.w3.org/TR/1999/REC-html401-19991224/struct/dirlan...

I discovered this as I was writing a paranoid HTML cleanup library and wanted to prevent the attack where a user sticks a text-direction-change character into the page and reverses the whole thing. As we've all just witnessed, that can't happen in a conforming browser.

But when viewing the page as a text stream, yup, it reverses and then never really unsticks. Everything's working as designed!

(Maybe my library should still restore the page flow after all... I never thought of how it could mess up view source. As attacks go, it's weak sauce... but like I said, it's meant to be really, really paranoid.)

Re: Can we believe our eyes? Misleading people with Unicode.

#43

On Linux, how could you make standard tools highlight or differentiate potentially misleading characters? I guess the solution would have to be in the terminal emulator? Would a blacklist of Unicode ranges be sufficient?

od -h -- I used to run into this problem a lot when I was writing grammars against different locales

Re: Can we believe our eyes? Misleading people with Unicode.

#44
Isn't the real issue that in order to be vulnerable to this, you have to be running as a user who has permission to diddle with the hosts file? Or that your hosts file has too-liberal write permissions?

Hosts file attacks are well-known enough that on windows I always set them to read-only, so that even administrators can't change them without first clearing the read-only flag.

Re: Can we believe our eyes? Misleading people with Unicode.

#46
post #27
post #14

Earlier quoted context omitted.

This is not a canonicalization attack. Those attacks are based on there being multiple ways to encode the same unicode codepoint in utf8. A utf8 decoder should reject portions of utf8 streams that don't use the shortest possible encoding, but not all do. If there are multiple ways to encode ' The attack described here is simpler: two unicode codepoints, roman 'o' and cyrillic 'o', usually look identical. So by substi…

> A utf8 decoder should reject portions of utf8 streams that don't use the shortest possible encoding so you would say that there should be no file names using the cyrillic o? So if a russian-speaking person wants to save a file, that file name should be rejected? Or translated into a mish-mash between cyrillic and roman characters? How will that work if that filename is reused on a system on which the default font d…

you shouldn't restrict anything - just give the users enough hints to be more informed.

I would highlite the background of any character that is not from the users codepage in red.

for eg. if your local settings are us-en, any character not from that codepage will have a red background (or even in italics, some way to signify that the character is 'foreign')

Re: Can we believe our eyes? Misleading people with Unicode.

#47
post #24

Earlier quoted context omitted.

This is not a canonicalization attack, although it is similar. The attacks described used semantically different strings that just happened to look like what the user was expecting.

I believe it's called a "homograph attack", or at least that's one name for it. Wikipedia has an article on the internationalized-domain-name version of the attack, and the various attempts by registrars and browsers to mitigate it: http://en.wikipedia.org/wiki/IDN_homograph_attack

On the same page. You can call them "Homograph Spoofing Attacks"

Re: Can we believe our eyes? Misleading people with Unicode.

#48
post #16
post #12

Earlier quoted context omitted.

Looks like the bug is in Chrome's View Source - the markup itself is fine.

Is it a bug? Or is chrome correctly interpreting the right-to-left override character it sees in the source?

Good point. It is probably the right thing to do technically, since the source view can't rely on parsing the markup. I think I'd prefer such non-printable characters to be simply escaped though.

Re: Can we believe our eyes? Misleading people with Unicode.

#49
post #21
post #11

Seems easy enough to guard against. Highlight the characters which are unexpected for my locale.

That's a clever idea, but I don't know how one would determine what "unexpected" is an increasingly international world.

nodata told you. Highlight characters not expected in my locale. My locale right now is en_US.utf-8. In security-sensitive contexts like file names and domain names, it's not actually that hard to figure out which characters are a surprise for me. And if I have a file that is named entirely in non-ASCII-subset characters... which I do... then light them all up. It's OK. It won't be hard for users to figure out what's going on, even if only subconsciously.

Re: Can we believe our eyes? Misleading people with Unicode.

#50
post #44

Isn't the real issue that in order to be vulnerable to this, you have to be running as a user who has permission to diddle with the hosts file? Or that your hosts file has too-liberal write permissions? Hosts file attacks are well-known enough that on windows I always set them to read-only, so that even administrators can't change them without first clearing the read-only flag.

Check out the second example, where you can have a .exe file show up as a .jpg, which is much, much nastier.
Post reply on HN