Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Can we believe our eyes? Misleading people with Unicode.

blogs.technet.com

Post reply on HN
Print view View original

31–40 of 128 posts

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

#31

Post by cyann »

pilif wrote: post #27
cbr wrote: 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…

A simpler fix would be to allow only ASCII characters in system folders.

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

#32

Post by adobriyan »

neilk wrote: post #21
nodata wrote: 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.

Code point has script property and mixing it inside strings which aren't likely to contain multiscript code points (like filenames) is a sign of trouble.

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

#33

Post by adobriyan »

cyann wrote: post #31
pilif wrote: post #27

Earlier quoted context omitted.

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

A simpler fix would be to allow only ASCII characters in system folders.

So the "fix" will only work in system folders.

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

#34

Post by cbr »

pilif wrote: post #27
cbr wrote: 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…

    > 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?
I'm sorry, I was unclear. I should have said "don't use the shortest possible encoding for a code point". Cyrillic 'o' is code point U+043E while roman 'o' is code point U+006F. The canonicalization attack relies on overly liberal utf8 decoders that would allow multiple binary streams to be interpreted as, say, code point U+006F.

This looks like the canonicalization attack, but is a different problem, one that is not solved by fixing decoders.

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

#35

Post by cbr »

yahelc wrote: post #26
nzmsv wrote: post #12

Earlier quoted context omitted.

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

Are you sure? curling from Terminal, I get the same result.

That's probably because your terminal interprets the RLO character. Should it? I'm not sure.

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

#36

Post by cbr »

adobriyan wrote: post #32
neilk wrote: post #21

Earlier quoted context omitted.

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

Code point has script property and mixing it inside strings which aren't likely to contain multiscript code points (like filenames) is a sign of trouble.

Then I could spell "hosts" entirely with cyrillic characters. (I'm not sure if it's possible with the word "hosts", but there's probably some word.)

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

#37

Post by _delirium »

maaku wrote: post #24
matthavener wrote: post #7

This is why "filters" that prevent XSS, etc by remove malicious characters are so easily breakable. This type of attack is called a canonicalization attack (more here https://www.owasp.org/index.php/Canonicalization,_locale_and... )

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

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

#38

Post by shrikant »

Blarat wrote: post #30
juliano_q wrote: post #25

Earlier quoted context omitted.

Since Windows by default don't show hidden files, I must say that most of my engineer coleagues would fall in the trick. Sadly, most people that I worked open the files manually.

I find that disturbing, one of the first things I do after a clean install of windows is to check the "Show Hidden Files", which was hard to find in Windows 7 :/ I thought most tech savvie people did that?

I wonder why you say it was hard to find - it's always been under the View tab in Folder Options.

Maybe because of the Control Panel revamp, or the fact that the menu-bar is hidden by default in Explorer windows?

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

#39

Post by epochwolf »

Blarat wrote: post #30
juliano_q wrote: post #25

Earlier quoted context omitted.

Since Windows by default don't show hidden files, I must say that most of my engineer coleagues would fall in the trick. Sadly, most people that I worked open the files manually.

I find that disturbing, one of the first things I do after a clean install of windows is to check the "Show Hidden Files", which was hard to find in Windows 7 :/ I thought most tech savvie people did that?

I don't. I generally leave that off, especially on my mac. If I want to see hidden files, I launch a terminal and list all files.

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

#40

Post by adobriyan »

cbr wrote: post #36
adobriyan wrote: post #32

Earlier quoted context omitted.

Code point has script property and mixing it inside strings which aren't likely to contain multiscript code points (like filenames) is a sign of trouble.

Then I could spell "hosts" entirely with cyrillic characters. (I'm not sure if it's possible with the word "hosts", but there's probably some word.)

Maybe you could. Anyway you could do it right now as well.

I doubt there is an acceptable non-heuristic solution.

Post reply on HN