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




11 years ago
8 years ago


(Reporter: Bjoern Hoehrmann, Assigned: jduell)


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

Firefox Tracking Flags

(Not tracked)




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


   <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?


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?


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:


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

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

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

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

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


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
Ever confirmed: true
Flags: blocking1.9?
Whiteboard: [sg:investigate]


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.


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+

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


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


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.