355010 - [1.8 branch]"Short" IDN components cause truncation of domain name

Status: RESOLVED WONTFIX

(Core :: Networking, defect, P2)

Description

[Bjoern Hoehrmann]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2)
Build Identifier: 

Consider

   <a href="http://ö...ö.example.de.invalid/">...</a>

If there are 58 ö characters, the domain name will be properly converted to xn--ndaaaa...example.de.invalid. If there are less, say 57, the domain name is truncated to "xn--ndaa...aa.exam". I suppose this is related to the encoded component having a length of 63 characters, the maximum length of a component.

I cannot rule out the possibility that there is some way to exploit this to bypass same origin restrictions. It can be used to successfully bypass means implemented in web applications to filter out certain user-defined references.

Reproducible: Always

Comment 1

[Gervase Markham [:gerv]]

Neil: can you check this out?

Gerv

Comment 2

[Neil Harris]

This is a tricky one: the problem is not "is this wrong?" (it clearly is), but "what is the right thing to do, under these circumstances?"

If I remember correctly, Punycoding is specified to fail if it would generate an overlength string, but I think the current code does not to allow for this possibility.

I can think of three possible approaches:
* make Punycoding return an error, and then handle this in all callers of the relevant code: this will require substantial work
* make Punycoding return a string which cannot be looked up in DNS, and is always the same, eg "xn-OVERLENGTH_DNS_LABEL!!"  
* make Punycoding return a string which cannot be looked up in DNS, and is always different, eg "xn-OVERLENGTH_DNS_LABEL!!=ööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööööö"

Any other ideas?

Comment 3

[Bjoern Hoehrmann]

(In reply to comment #2)
> If I remember correctly, Punycoding is specified to fail if it would generate
> an overlength string, but I think the current code does not to allow for this
> possibility.

I am not sure you understood the bug report, Mozilla transforms the domain names as follows:

1234567890123456789012345678901234567890123456789012345678901234567890123456
0000000001111111111222222222233333333334444444444555555555566666666667777777

ööööööööööööööööööööööööööööööööööööööööööööööö.example.invalid => 
ööööööööööööööööööööööööööööööööööööööööööööööö.example.invali

öööööööööööööööööööööööööööööööööööööööööööööööö.example.invalid =>
öööööööööööööööööööööööööööööööööööööööööööööööö.example.inval

ööööööööööööööööööööööööööööööööööööööööööööööööö.example.invalid =>
ööööööööööööööööööööööööööööööööööööööööööööööööö.example.inva

ööööööööööööööööööööööööööööööööööööööööööööööööööööööööö.example.invalid =>
ööööööööööööööööööööööööööööööööööööööööööööööööööööööööö.exam

öööööööööööööööööööööööööööööööööööööööööööööööööööööööööö.example.invalid =>
öööööööööööööööööööööööööööööööööööööööööööööööööööööööööö.example.invalid

1234567890123456789012345678901234567890123456789012345678901234567890123456
0000000001111111111222222222233333333334444444444555555555566666666667777777

The problem occurs with labels of a proper length.

Comment 4

[Neil Harris]

OK. I understand what you mean now. Yes, that's completely different to what I thought was happening.

Comment 5

[Neil Harris]

This issue may be related to bug 355425.

Comment 6

[Mike Schroepfer]

Hey Neil - any new thoughts on what to do with this bug?

Comment 7

[Jesse Ruderman]

Neil, are you going to be able to fix this soon?  If not, please reassign it to the address [e-mail] so it will show up on the list of 1.9 blockers without owners.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Not gonna block on this, renom if you think we're missing some critical reason for fixing.

Comment 9

[Jason Duell]

I'm adding this to my list of likely network bugs to work on.  No guarantee when I'll actually get to it.

Comment 10

[Daniel Veditz [:dveditz]]

The original comment 0 and examples in comment 3 apply to the 1.8 branch; 1.9 does not exhibit this problem.

Neil's comment 2 is a separate issue and does still happen in 1.9.x. When an IDN part gets overlong we stop converting to punycode and display the IDN even for TLDs that are not supposed to have IDN characters. Not sure we're actually trying to ping the DNS for those, I'll check when I get wireshark running again.

If you set network.IDN_show_punycode to true then when the IDN component gets overlong the whole host goes away, leaving http:/// (three slashes). This isn't really right, either, but it's interesting that it's a different failure than the IDN-on-but-punycode-TLD case.

Comment 11

[Neil Harris]

I think this bug needs more investigation. This is a tricky and complex set of code paths, and although this bug in its reported form may not directly affect security, the code paths involved, and some of the related issues such as the comment 2 issue, may well do so.