Normalization of some FQDN labels can give rise to all-ASCII strings which contain characters which are illegal in RFC 1035 domain names, for example, slash characters. See bug 309128 for test cases, and in particular the test case in bug 308800. This appears to be due to some _non-ASCII_ Unicode characters being mapped by NAMEPREP _into ASCII characters_, including punctuation characters, thus resulting in all-ASCII strings containing bogus DNS characters, even when no such characters appear in the input. The Punycode logic then passes them right through to the DNS logic. Presumably the the bug arises from the illegal character check currently being carried out before NAMEPREP normalization of the FQDN labels: it should clearly be carried out _after_ NAMEPREP normalization. Or perhaps the code is even cruder, and just blindly trusts the URL parser to catch all illegal characters at parse time -- which would be a bad idea, since such a parser is inevitably complex, and likely to be a place where obscure bugs may remain hidden for long periods.

This has been filed as a more fine-grained bug to deal with one specific issue from bug 309128, namely the smuggling of bogus ASCII characters through the DNS name/hostname code.

This bug is about fixing the NAMEPREP/character-checking logic, not about fixing the DNS lookup code (which is bug 304904 and friends), right? Given that we have the check in the DNS lookup code, is there still a security issue here? Gerv

dveditz, can you comment here? thanks.

we're wrapping up this release tonight and this isn't moving so it's probably not going to make it.

(In reply to comment #2) > bug 304904 and friends) Given that we have > the check in the DNS lookup code, is there still a security issue here? Yes, because the actual 304904 checkin was too limited.

*** This bug has been marked as a duplicate of 316444 ***