204682 - (liu2) Same-origin violation with extra dot in hostname

Status: VERIFIED FIXED

(Core :: Security, defect)

Description

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 1

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 2

[Mitchell Stoltz (not reading bugmail)]

Attachment: Patch - don't allow setting document.domain to empty string

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.

Comment 3

[georgi - hopefully not receiving bugspam]

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 4

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 5

[Darin Fisher]

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.)

Comment 6

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 7

[Christopher Blizzard (:blizzard)]

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

Comment 8

[Samir Gehani]

adt: nsbeta1+/adt1

Comment 9

[Daniel Veditz [:dveditz]]

This should definitely block 1.4, putting on radar

Comment 10

[Jesse Ruderman]

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?

Comment 11

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 12

[Charles Rosendahl]

Plussing per edt meeting

Comment 13

[Heikki Toivonen (remove -bugzilla when emailing directly)]

FYI, this was fixed on 05/09/2003 16:56 on the trunk.

Comment 14

[Paul Wyskoczka]

Updating qa contact to [e-mail]

Comment 15

[Charles Rosendahl]

I've verified these around May 15th and everything in this particular defect was
fixed.

Charles

Comment 16

[Paul Wyskoczka]

Based on Charles' comments marking verified