310361 - Some Unicode characters can generate bogus ASCII in domain names

Status: RESOLVED DUPLICATE of bug 316444

(Core :: Networking, defect)

Description

[Neil Harris]

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.

Comment 1

[Neil Harris]

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.

Comment 2

[Gervase Markham [:gerv]]

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

Comment 3

[Asa Dotzler [:asa]]

dveditz, can you comment here? thanks.

Comment 4

[Asa Dotzler [:asa]]

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

Comment 5

[Daniel Veditz [:dveditz]]

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

Comment 6

[Neil Harris]

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