Closed Bug 204682 (liu2) Opened 17 years ago Closed 17 years ago

Same-origin violation with extra dot in hostname

Categories

(Core :: Security, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla1.4final

People

(Reporter: security-bugs, Assigned: security-bugs)

Details

(Keywords: topembed+, Whiteboard: [adt1])

Attachments

(1 file)

Our friend in China is at it again. This is from Bugtraq:

URL "http://[Domain]./[DirectoryName]/[FileName]"(one more dot 
after "[Domain]") will actually navigate your browser to:
"http://[Domain]/[DirectoryName]/[FileName]".
then "document.domain" is "[Domain]."(one more dot in "document.domain").

try to execute javascript:
[CODE.JAVASCRIPT]document.domain=""

after being set to an empty string, document.domain is auto-caculated to 
be [DirectoryName].
of course, "[DirectoryName]" can be "www.paypal.com", but you still cannot 
access document at "www.paypal.com" by just having "www.paypal.com" 
as "document.domain".

now, you make "document.domain" to be "w.www.paypal.com", then set it 
to "www.paypal.com". 
you can access document at "www.paypal.com" now.

Example at http://liudieyuinchina.vip.sina.com/DomainDot/DomainDot-MyPage.htm

I still need to verify this.
On the trunk, this attack is succesful at changing document.domain to an
arbitrary value, but it can't be used for a same-origin violation unless the
other site has also set document.domain, because of the "both must set domain
explicitly" restriction we added. However, builds from before we added that
restriction are vulnerable to this. I will tighten up the document.domain
security check to prevent this - we may also want to change Necko to not accept
a trailing dot in a hostname.

This isn't exploitable as is on the trunk, but there's probably a related
exploit. In any case, being able to set document.domain arbitrarily is really
scary and I want to get this fixed for 1.4, so I'm nominating it.
Status: NEW → ASSIGNED
Flags: blocking1.4?
Keywords: nsbeta1, topembed
This fixes the exploit, but I haven't convinced myself there isn't some other
sneaky things one could do to confuse this security check. I'll keep looking.
For comment #1 "...we may also want to change Necko to not accept
a trailing dot in a hostname..."
I am not sure this is an option, though I like restricting stuff :)
AFAIK trailing dot has special meaning in DNS client stuff. AFAIK it means don't
 search any local domains and resolve the exact name from DNS server.
For example on linux:
ping www.yahoo.com.
(note the trailing dot) does work.
I have seen an URL containing trailing dot in the wild in the internet and it
was a legitimate one.
Comment on attachment 122722 [details] [diff] [review]
Patch - don't allow setting document.domain to empty string

Reviewers: Do you think simply disallowing the empty string as a domain will
prevent all attacks here, or should we be even more strict? Georgi and I are
trying to think of alternate, related attacks, but haven't found any yet.
Attachment #122722 - Flags: superreview?(darin)
Attachment #122722 - Flags: review?(heikki)
Alias: liu2
Comment on attachment 122722 [details] [diff] [review]
Patch - don't allow setting document.domain to empty string

sr=darin (looks right on to me... will think about other ways to possibly
exploit using something like this.)
Attachment #122722 - Flags: superreview?(darin) → superreview+
Attachment #122722 - Flags: review?(heikki) → review+
Target Milestone: --- → mozilla1.4final
Comment on attachment 122722 [details] [diff] [review]
Patch - don't allow setting document.domain to empty string

Requesting drivers approval for 1.4. This patch just prevents setting
document.domain to the empty string, and removes an unneeded comparison.
Attachment #122722 - Flags: approval1.4?
Comment on attachment 122722 [details] [diff] [review]
Patch - don't allow setting document.domain to empty string

a=blizzard on behalf of drivers for 1.4
Attachment #122722 - Flags: approval1.4? → approval1.4+
adt: nsbeta1+/adt1
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt1]
This should definitely block 1.4, putting on radar
Flags: blocking1.4? → blocking1.4+
On Bugtraq 4/29, so removing security-sensitive flag.
<http://archives.neohapsis.com/archives/bugtraq/2003-04/0362.html>

Mitch, are you planning to fix this on the 1.0 branch?
Group: security
Fix checked in.

I'm not checking in fixes to the 1.0 branch anymore because it will shortly be
replaced by 1.4 as the stable branch. If anyone wants fixes on the 1.0 branch
they will need to seek checkin approval on their own - I don't think another
1.0.x release is planned.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Plussing per edt meeting
Keywords: topembedtopembed+
FYI, this was fixed on 05/09/2003 16:56 on the trunk.
Updating qa contact to bmartin@netscape.com
QA Contact: carosendahl → bmartin
I've verified these around May 15th and everything in this particular defect was
fixed.

Charles
Based on Charles' comments marking verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.