Closed Bug 204682 (liu2) Opened 17 years ago Closed 17 years ago
Same-origin violation with extra dot in hostname
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.
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.
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+
17 years ago
Attachment #122722 - Flags: review?(heikki) → review+
17 years ago
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+
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?
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
FYI, this was fixed on 05/09/2003 16:56 on the trunk.
Updating qa contact to email@example.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.