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

RESOLVED WONTFIX

Status

()

Core
Networking
P2
normal
RESOLVED WONTFIX
11 years ago
8 years ago

People

(Reporter: Bjoern Hoehrmann, Assigned: jduell)

Tracking

1.8 Branch
x86
Windows Server 2003
Points:
---
Bug Flags:
wanted-next +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
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
Neil: can you check this out?

Gerv

Comment 2

11 years ago
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?

(Reporter)

Comment 3

11 years ago
(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

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

Comment 5

11 years ago
This issue may be related to bug 355425.
Assignee: nobody → usenet
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?
Whiteboard: [sg:investigate]

Updated

11 years ago
Flags: blocking1.9? → blocking1.9+

Comment 6

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

Comment 7

10 years ago
Neil, are you going to be able to fix this soon?  If not, please reassign it to the address nobody@mozilla.org so it will show up on the list of 1.9 blockers without owners.

Updated

10 years ago
Assignee: usenet → nobody
Priority: -- → P2
Not gonna block on this, renom if you think we're missing some critical reason for fixing.
Flags: tracking1.9+ → wanted-next+
(Assignee)

Comment 9

9 years ago
I'm adding this to my list of likely network bugs to work on.  No guarantee when I'll actually get to it.
Assignee: nobody → jduell
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.
Version: Trunk → 1.8 Branch
Summary: "Short" IDN components cause truncation of domain name → [1.8 branch]"Short" IDN components cause truncation of domain name

Updated

8 years ago
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
Whiteboard: [sg:investigate]

Updated

8 years ago
Group: core-security

Comment 11

8 years ago
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.
You need to log in before you can comment on or make changes to this bug.