3 ms·

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 (mor

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_Unicode https://www.owasp.org/index.php/Canonicalization,_locale_and...)

cbr 15y ago
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 '<', then an xss prevention filter is going to have trouble. The attack described here is simpler: two unicode codepoints, roman 'o' and cyrillic 'o', usually look identical. So by substituting cyrillic we can make a file called 'hosts' that the operating system won't pay attention to. This is the same problem with punycode internationalized domain names, where paypal.com might be spelled with a cyrillic 'a' and mislead people. The fix for domain names was to restrict what unicode you could use where. I'm not sure what the fix is here, aside from always showing hidden files.
- pilif 15y ago
  > 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 doesn't contain the roman characters (I'm sure such a thing exists) and thus font substitution needs to happen? The fix definitely isn't this easy. Maybe one could disallow homoglyphs of a different language than the one dominating the current file name. But this might be a lot of work and I doubt it's fool-proof.
  - cyann 15y ago
    A simpler fix would be to allow only ASCII characters in system folders.
    - adobriyan 15y ago
      So the "fix" will only work in system folders.
      - bronson 15y ago
        The "problem" described only exists in system folders.
  - cbr 15y ago
    > 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.
    - Sephr 15y ago
      The Cyrillic o isn't being interpreted as U+006F, it just looks like it. A UTF-8 decoder doesn't know how it's output is going to be used.
      - sesqu 15y ago
        That's not the point. The attack relies on some nonconforming decoders exhibiting a many-to-one mapping of bitstreams to codepoints, changing the semantics of the bistream.
  - nikcub 15y ago
maaku 15y ago
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.
- _delirium 15y ago
  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 http://en.wikipedia.org/wiki/IDN_homograph_attack
  - 0xdeadc0de 15y ago
    On the same page. You can call them "Homograph Spoofing Attacks"

cbr 15y ago

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 '<', then an xss prevention filter is going to have trouble. The attack described here is simpler: two unicode codepoints, roman 'o' and cyrillic 'o', usually look identical. So by substituting cyrillic we can make a file called 'hosts' that the operating system won't pay attention to. This is the same problem with punycode internationalized domain names, where paypal.com might be spelled with a cyrillic 'a' and mislead people. The fix for domain names was to restrict what unicode you could use where. I'm not sure what the fix is here, aside from always showing hidden files.

pilif 15y ago
> 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 doesn't contain the roman characters (I'm sure such a thing exists) and thus font substitution needs to happen? The fix definitely isn't this easy. Maybe one could disallow homoglyphs of a different language than the one dominating the current file name. But this might be a lot of work and I doubt it's fool-proof.
- cyann 15y ago
  A simpler fix would be to allow only ASCII characters in system folders.
  - adobriyan 15y ago
    So the "fix" will only work in system folders.
    - bronson 15y ago
      The "problem" described only exists in system folders.
- cbr 15y ago
  > 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.
  - Sephr 15y ago
    The Cyrillic o isn't being interpreted as U+006F, it just looks like it. A UTF-8 decoder doesn't know how it's output is going to be used.
    - sesqu 15y ago
      That's not the point. The attack relies on some nonconforming decoders exhibiting a many-to-one mapping of bitstreams to codepoints, changing the semantics of the bistream.
- nikcub 15y ago

maaku 15y ago

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.

_delirium 15y ago
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 http://en.wikipedia.org/wiki/IDN_homograph_attack
- 0xdeadc0de 15y ago
  On the same page. You can call them "Homograph Spoofing Attacks"