The default bug view has changed. See this FAQ.

fail to check the IDN is in whitelist with un-normalized URL

VERIFIED FIXED in mozilla1.8.1

Status

()

Core
Networking
VERIFIED FIXED
12 years ago
11 years ago

People

(Reporter: masayuki, Assigned: Darin Fisher)

Tracking

(4 keywords)

Trunk
mozilla1.8.1
intl, testcase, verified1.8.0.2, verified1.8.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8rc2 -
blocking1.8.1 +
blocking1.8.0.1 -
blocking1.8.0.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:low] spoofing, requires user to type or paste URL [rft-dl])

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

12 years ago
if user inputs un-normalized URL in URL bar, we always fail to check the IDN is in whitelist or not so. Becuase we are checking un-normalized host.
(Reporter)

Comment 1

12 years ago
Created attachment 202111 [details] [diff] [review]
Patch rv1.0
Attachment #202111 - Flags: superreview?(darin)
Attachment #202111 - Flags: review?(darin)
(Reporter)

Updated

12 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 2

12 years ago
e.g.,
http://www.日本語。JP/
(Reporter)

Comment 3

12 years ago
Sorry, it cannot repro. Please use this instead.
http://日本語。JP/
(Reporter)

Comment 4

12 years ago
This can be reproduced when I hover the mouse cursor on comment 3's link. In this time, the status bar shows punycode URL.
(Assignee)

Comment 5

12 years ago
So, this allows our IDN whitelist to be defeated, which seems pretty bad.  Should this block the FF 1.5 release?
Flags: blocking1.8rc2?
(Assignee)

Comment 6

12 years ago
Created attachment 202136 [details] [diff] [review]
Patch rv1.1

Here's a slightly revised version of the patch.  The main problem with the v1.0 patch was that it was passing |result| as both an in-param as well as an out-param to ConvertUTF8toACE.  That could cause a problem in the future if ConvertUTF8toACE ever modified it's out-param before reading from the in-param, so I fixed the code to use a temporary string object.  I also added a few more comments.
Assignee: masayuki → darin
Attachment #202111 - Attachment is obsolete: true
Attachment #202136 - Flags: superreview+
Attachment #202136 - Flags: review?
Attachment #202111 - Flags: superreview?(darin)
Attachment #202111 - Flags: review?(darin)
(Assignee)

Updated

12 years ago
Attachment #202136 - Flags: review? → review?(jshin1987)
(Assignee)

Updated

12 years ago
Target Milestone: mozilla1.9alpha → mozilla1.8rc1
(Reporter)

Comment 7

12 years ago
thanks, Darin.
(Assignee)

Comment 8

12 years ago
Comment on attachment 202136 [details] [diff] [review]
Patch rv1.1

I think this patch is not good.  It introduces cases where .com domain names are displayed as unicode and sent to the DNS resolver as punycode.  See bug 315440.
Attachment #202136 - Attachment is obsolete: true
Attachment #202136 - Flags: review?(jshin1987)
(Assignee)

Updated

12 years ago
Depends on: 315440
(Assignee)

Comment 9

12 years ago
Created attachment 202187 [details] [diff] [review]
Patch rv1.2

OK, here's a revised patch.  I am falling back on ConvertUTF8toACE when Normalize fails.  This seems to address the problems that I found with malformed bidi text in bug 315440.

Masayuki: Can you please verify that this patch works as you expect.  Thanks.
Attachment #202187 - Flags: superreview?(dveditz)
Attachment #202187 - Flags: review?(jshin1987)
(Reporter)

Comment 10

12 years ago
This patch works fine for this patch.
But http://www.%E3%83%8F%E3%83%B3%E3%83%89%E3%83%9C%E3%83%BC%E3%83%AB%E3%82%B5%E3%83%A0%E3%82%BA.com
 is displaied UTF-8 URL on statusbar.
(Reporter)

Comment 11

12 years ago
> This patch works fine for this patch.

for this *bug*.

Comment 12

12 years ago
Is the seriousness of this bug mitigated somewhat by the fact that this is only a problem with urls the user enters by hand (as opposed to URLS the user clicks on from a web page and URLs that come from other applications (like mail)?

Comment 13

12 years ago
Comment on attachment 202187 [details] [diff] [review]
Patch rv1.2

r=jshin
Attachment #202187 - Flags: review?(jshin1987) → review+
(Reporter)

Comment 14

12 years ago
(In reply to comment #12)
> Is the seriousness of this bug mitigated somewhat by the fact that this is only
> a problem with urls the user enters by hand (as opposed to URLS the user clicks
> on from a web page and URLs that come from other applications (like mail)?
> 

On thunderbird, if a text mail has IDN URL in its content, thunderbird makes link the URL. But the URL cannot be opened on Firefox by clicking the URL. Maybe, it's another bug.
# I think that the bug is same the bug of comment 10.
(Assignee)

Comment 15

12 years ago
> # I think that the bug is same the bug of comment 10.

Yeah, the URL with %-escaped characters in the hostname cannot be loaded because Mozilla does not unescape the hostname portion of a URL.

Comment 16

12 years ago
my question wasn't about thunderbird at all. I was trying to ask if the bypassing of our IDN whitelist check is only happening for URLs a user manually types into the urlbar vs. urls clicked on from a web page or urls we are given by the OS as a result of a user clicking on urls from other applications (like mail, IM, etc).
(Assignee)

Comment 17

12 years ago
(In reply to comment #16)
> my question wasn't about thunderbird at all. I was trying to ask if the
> bypassing of our IDN whitelist check is only happening for URLs a user manually
> types into the urlbar vs. urls clicked on from a web page or urls we are given
> by the OS as a result of a user clicking on urls from other applications (like
> mail, IM, etc).

mscott:  I think that it is possible for any website to give the user links that contain un-normalized unicode characters in the hostname.  That means that, yes, our whitelist is *completely defeated* by this bug.  So, I think this is a serious bug that needs to block the 1.5 release.
Severity: minor → blocker
(Assignee)

Comment 18

12 years ago
Masayuki: Can you please confirm that this bug could be triggered by web content as well?

Comment 19

12 years ago
Created attachment 202278 [details]
testcase

This bug can be reproduced by the links on web page.

Comment 20

12 years ago
The subject implies that this bug effects urls typed into the url bar by the user only. We should clarify the summary if that's not the case Masayuki. 

Comment 21

12 years ago
Created attachment 202281 [details]
testcase 2

another tests added.
Attachment #202278 - Attachment is obsolete: true
(Assignee)

Comment 22

12 years ago
OK, I confused myself.  Comment #17 is wrong.  Without this patch, the only harm is that we will show punycode when we could safely show unicode to the user.  Therefore, this is really just a minor bug that websites can workaround.  I don't think we need to block FF 1.5 for this.  Sorry for the false alarm!
Severity: blocker → minor
Flags: blocking1.8rc2?
Target Milestone: mozilla1.8rc1 → mozilla1.9alpha
(Assignee)

Updated

12 years ago
Attachment #202187 - Flags: superreview?(dveditz)
(Assignee)

Comment 23

12 years ago
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

12 years ago
Keywords: testcase
Summary: fail to check the IDN is in whitelist if user inputs un-normalized URL in URL bar → fail to check the IDN is in whitelist with un-normalized URL

Comment 24

12 years ago
This bug was reported first by .jp registry to Mozilla Japan. IDN whitelist is a much-anticipated new feature and they hope the problem is fixed in Firefox 1.5, of course. Mozilla Japan also request blocking.
Flags: blocking1.8rc2?

Comment 25

12 years ago
because this is a case of us being over zealous as opposed to the white list being bypassed to show things in unicode that should be show in punycode, we aren't going to respin and slip the release for this fix. Let's look into getting it into the next follow up release.
Flags: blocking1.8rc2? → blocking1.8rc2-

Comment 26

12 years ago
ugh. we'll escalate the issue to MoCo through official channels...
(Reporter)

Comment 27

12 years ago
Let's go to next minor release. This bug was reported by JPRS.
Flags: blocking1.8.1?
(Reporter)

Comment 28

12 years ago
I filed a bug of comment 10. See bug 315666.
(Reporter)

Comment 29

12 years ago
(In reply to comment #20)
> The subject implies that this bug effects urls typed into the url bar by the
> user only. We should clarify the summary if that's not the case Masayuki. 
> 

Oops. Sorry. The old summary is wrong. This is reproduced by the link of web contents too. But this is not a security bug.

I think that we should go to 1.8.1, this bug and bug 315666.
Severity: minor → normal

Updated

12 years ago
Flags: blocking1.8.0.1?
Whiteboard: [sg:low] spoofing, requires user to type or paste URL
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1-
(Reporter)

Comment 30

11 years ago
Comment on attachment 202187 [details] [diff] [review]
Patch rv1.2

This is minor problem. But the patch doesn't have regression report. And this bug is reported by JPRS.
Attachment #202187 - Flags: approval1.8.1?
Attachment #202187 - Flags: approval1.8.0.1?
Flags: blocking1.8.0.2?
Comment on attachment 202187 [details] [diff] [review]
Patch rv1.2

Not for 1.8.0.1 (candidates in hand).
Attachment #202187 - Flags: approval1.8.0.2?
Attachment #202187 - Flags: approval1.8.0.1?
Attachment #202187 - Flags: approval1.8.0.1-
(Reporter)

Updated

11 years ago
Attachment #202187 - Flags: branch-1.8.1?(darin)
Attachment #202187 - Flags: approval1.8.1?
(Assignee)

Updated

11 years ago
Attachment #202187 - Flags: branch-1.8.1?(darin) → branch-1.8.1+
(Reporter)

Updated

11 years ago
Keywords: fixed1.8.1
Target Milestone: mozilla1.9alpha → mozilla1.8.1
Flags: blocking1.8.0.2? → blocking1.8.0.2+
Comment on attachment 202187 [details] [diff] [review]
Patch rv1.2

approving for 1.8.0 branch, a=dveditz for drivers
Attachment #202187 - Flags: approval1.8.0.2? → approval1.8.0.2+
(Reporter)

Updated

11 years ago
Keywords: fixed1.8.0.2
(Reporter)

Comment 33

11 years ago
-> v.(trunk and 1.8 branch)
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1 → verified1.8.1

Updated

11 years ago
Whiteboard: [sg:low] spoofing, requires user to type or paste URL → [sg:low] spoofing, requires user to type or paste URL [rft-dl]

Comment 34

11 years ago
v.fixed on 1.8.0 branch with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2, links in testcase 2 work as expected.
Keywords: fixed1.8.0.2 → verified1.8.0.2
You need to log in before you can comment on or make changes to this bug.