New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users
Status: Fixed
Owner:
Closed: Oct 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security



Sign in to add a comment
Security: SDCH dictionary URL check can be bypassed
Project Member Reported by nya@chromium.org, Jun 27 2014 Back to list
VULNERABILITY DETAILS

One can bypass SDCH dictionary URL check by adding a trailing dot to the URL.

SDCH spec forbids installing an SDCH dictionary for example.com from x.y.z.example.com:

> A dictionary is invalid and must not be stored if any of the following are true:
> ...
> 4. The referrer URL host is a host domain name (not IP address) and has the form HD, where D is the value of the Domain attribute, and H is a string that contains one or more dots.

In fact, an attempt to install a dictionary for example.com from http://x.y.z.example.com/ is rejected. However, if one accesses the page as http://x.y.z.example.com./ (notice the trailing dot), the dictionary is accepted.


VERSION

Chrome Version: 37.0.2062.0 dev
Operating System: Linux


REPRODUCTION CASE

If you're on Google internal network: https://goto.google.com/mgwph
This page installs an SDCH dictionary for .google.com.

 
Comment 1 by rsesek@chromium.org, Jun 27 2014
Labels: Security_Severity-Low Security_Impact-Stable Security_Impact-Beta M-37
Owner: rdsmith@chromium.org
Status: Assigned
rdsmith: Can you take a look at this and route appropriately?
Cc: jar@chromium.org cbentzel@chromium.org
I'm the right person for this to be assigned to.  

IMO, given the current use of SDCH (pretty much only Google search results), I don't consider this bug very high priority.  If it isn't high priority, I'm not likely to get to it before July 7th (other tasks today, vacation next week), which may jeopardize being able to merge it into M-37.  Ccing the folks that might want to try and convince me that it should have a higher priority that that.
Project Member Comment 3 by ClusterFuzz, Jul 28 2014
Labels: -Security_Impact-Beta
Project Member Comment 4 by ClusterFuzz, Jul 29 2014
Labels: Security_Impact-Beta
Project Member Comment 5 by ClusterFuzz, Jul 29 2014
Labels: -Security_Impact-Beta
Project Member Comment 6 by ClusterFuzz, Jul 29 2014
Labels: Security_Impact-Beta
Project Member Comment 7 by ClusterFuzz, Jul 29 2014
Labels: -Security_Impact-Beta
Project Member Comment 8 by ClusterFuzz, Jul 30 2014
Labels: -Security_Impact-Stable Security_Impact-Beta
Labels: -Security_Impact-Beta Security_Impact-Stable
Cc: sidv@chromium.org
Labels: -M-37 M-39
rdsmith: Please try to have a fix in for M39. Looks pretty small as well given description.
Labels: -Pri-2 Pri-1
Cc: gavinp@chromium.org rdsmith@chromium.org
Current status: This is a bug in the spec.  The spec says that you can use a dictionary if a domain matches a URL (correct) and that you can store a dictionary unless one of several things are true, the relevant one of which is:

"The referrer URL host is a host domain name (not IP address) and has the form HD, where D is the value of the Domain attribute, and H is a string that contains one or more dots."

The problem is that a URL can domain match without the domain being a suffix of the host; specifically, a trailing . still domain matches.  

I'm trying to figure out what the right spec change is, and then whether we should change the spec or code first.  I'm inclined to think that this isn't too bad a bug, so it's ok to change the spec first (and thus advertise this vulnerability in chrome) but I'm open to counter-arguments.

Cc: rsleevi@chromium.org
Giving my CL reviewer access to the bug.  Ryan: As noted in the CL, I no longer think this is a problem in the spec.

(https://codereview.chromium.org/574283006/ if anyone else wants to take a look.)
Project Member Comment 15 by bugdroid1@chromium.org, Sep 23 2014
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/14fd659a2284bc9f301828ada49b8d3fe1f80550

commit 14fd659a2284bc9f301828ada49b8d3fe1f80550
Author: rdsmith <rdsmith@chromium.org>
Date: Tue Sep 23 21:13:10 2014

Fix dictionary domain check problem.

Previous to this change, suffixing a "." to the URL from which a
dictionary was being suggested would allow servers to bypass the
check against a subdomain (e.g. evil.protected.good.com) setting a
dictionary to be used by a superdomain (.good.com).

BUG= 389451 
R=rsleevi@chromium.org

Review URL: https://codereview.chromium.org/574283006

Cr-Commit-Position: refs/heads/master@{#296246}

[modify] https://chromium.googlesource.com/chromium/src.git/+/14fd659a2284bc9f301828ada49b8d3fe1f80550/net/base/sdch_manager.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/14fd659a2284bc9f301828ada49b8d3fe1f80550/net/base/sdch_manager_unittest.cc

Status: Fixed
Project Member Comment 17 by ClusterFuzz, Oct 14 2014
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: Release-0-M39
Project Member Comment 19 by ClusterFuzz, Jan 19 2015
Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Project Member Comment 20 by sheriffbot@chromium.org, Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member Comment 21 by sheriffbot@chromium.org, Oct 2 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic
Sign in to add a comment