4 ms·

It creates a parser differential; two different components of the system can treat the same string as different hostnames. Things that have trusted hostnames, o

• tialaramex 2mo ago
  It is situational, but it very much seems like a thing you'd squirrel away and bring out when you find a system where the differential is helpful. DNS names are a thing where Sales is going to tell the Engineer that they can't issue the customers randomized ASCII names like abxuewrf.my-thing.example because real customers want to write our-brand-name.my-thing.example instead - even though you already know bad guys will choose billing.my-thing.example and name-of-bank.my-thing.example and every other unintended bad choice even before we realise about likelihood of these confusion bugs in software like Python.
  • xp84 2mo ago
    That's why for that type of 'semi-white-label' thing, since the main risk is one of impersonating the platform owner (like the billing.my-thing.example) or possibly lending the credibility of "our" brand to some rando UGC, I always push for the most boring and generic second-level domain, like if it's the travel business, 'travel-systems dot us' or in edtech, mylearningplatform dot net... Then push all customers who know what they're doing into 'BYO DNS name' anyway. I also like how sites like github use githubusercontent.com or something like that when linking to UGC assets directly, to avoid someone direct linking to something with the implication that it's coming from GitHub.
    • chuckadams 2mo ago
      It's mostly about not sharing a security context with github.com.
      • cwillu 2mo ago
        Yes, but github.cc or whatever would have sufficed for that; there's a reason the string they chose to register for prominent public use contains “usercontent”
        • inigyou 2mo ago
          literally github.io though
          • notpushkin 2mo ago
            And before that one, user content was hosted on *.github.com! Wild times.
    • inigyou 2mo ago
      That's actually to prevent cookie stealing.
      • lozenge 2mo ago
        Yes, involving the Public Suffix List. It's quite ridiculous you need to register your domain on a list of you want to offer subdomains.
  • inigyou 2mo ago
    Solution: customer emails you to request a name
    • deleted 2mo ago
      [deleted]
    • zrm 2mo ago
      How does the customer service rep tell that a name with some Unicode gubbins is an attack rather than a customer from Juárez or 서울? Having a busy hand copy and paste the attacker-provided string into the system doesn't get you out of it.
      • schluss-s 2mo ago
        "Juárez" can be done with ASCII tho
        • tialaramex 2mo ago
          > "Juárez" can be done with ASCII tho No it can't? Are you thinking of ISO-8859-1 or Windows codepage 1252 maybe?
      • inigyou 2mo ago
        Do you sell to Korea? If so, ask the Korea team. If not, don't allow it.
      • wildzzz 2mo ago
        Simple but less culturally sensitive solution: English is the linga franca so tell them to either romanize their company name or come up with a brand name using latin characters. 삼성전자 can be written as Samseong jeonja in latin characters and translated literally as Tristar Electronics but they do business as samsung.com I think it's cool that we figured out a way to encode CJK and other foreign script into ASCII-only domain names but if there's a serious concern about opening yourself to domain spoofing because someone picked the wrong encoding, just use ASCII characters.
• TZubiri 2mo ago
  I can see how this would be a vulnerability in the context of a security researcher that wants to exaggerate their findings in order to get paid a bounty.
• raverbashing 2mo ago
  From what I understand the vulnerability is not on lower() but on using different Unicode rules version for it That sounds to me like a better explanation
• cobbzilla 2mo ago
  IDN is a security flaw masquerading as a standard.
  • pseudohadamard 2mo ago
    Nice! Although I'd perhaps put it as "IDN is a come-hither sign for attackers masquerading as ...".
• belorn 2mo ago
  Not all Unicode characters are permitted in DNS, so the parser differential need to exist within the allowed set of Unicode characters. For example, a parser differential on a "space" unicode character won't impact a list of trusted hostnames, since space are not allowed in the first place. Looking at examples where it could matter, German Sharp S (ß) is allowed in domain names and so a list of trusted hostnames could be fooled if one hostname had a double ss idn-encoded name and the attacker registered a second domain with ß, but there is a caveat here. Looking at how .eu registry handle it, they will not allow two domains to only have the difference between ss and ß, unless they are the same registrant and explicitly request to have both variants (https://eurid.eu/en/knowledge-centre/domain-names-with-special-characters-idns/ https://eurid.eu/en/knowledge-centre/domain-names-with-speci...). Thus the attack vector will depend on if the registry has protection against it or not.
• pseudohadamard 2mo ago
  It's a big deal in anything dealing with permitted/excluded names because once you take the insane C/Posix locale rules into account you end up with nondeterministic comparison results: compare a with b, get a match, another thread changes the locale setting, compare the same a with b, get a non-match. You've also got nontransitive case-changes, e.g. toupper('ı') = 'I', tolower('I') = 'i', 'ı' != 'i'. This means that an attacker can get around any name-based checks by choosing a character set that compares however they want it to, which is why a lot of OSS security projects implement their own guaranteed-deterministic comparison functions, e.g. WireGuard's built-in replacement for the ctype.h macros/functions.