Oh, also an easy fix to this would be to have SdchDictionaryFetcher override OnReceivedRedirect to enforce the security policy.

Thanks for the report, nice find. I'm not especially familiar with SDCH but the cross-domain data leak potential seems to warrant medium severity.

rdsmith: Can you handle this one?

Is this actually a security problem assuming that we restrict to https only (if this crosses https to http that should be addressed).

Presumably whoever can introduce the 302 in step 2 could also simply replace the content of the dictionary as well - so delegating to another domain doesn't introduce a new security threat. 

So currently it does cross https->http or back.  But I think it's a security problem even without that.  When the dictionary is entered into the SDCH manager it is recorded as coming from the final (target of redirect) domain.  Thus a URL that a domain didn't intend to have used as a dictionary could be forced by evil.com to be used as a dictionary for that domain.  evil.com wouldn't have a lot of control over the contents of that dictionary (it would have to be a file served from the target domain) but it's still a theoretical vulnerability.  

I don't think I agree with "Medium", though; that attack would be pretty hard to execute.  kenrb@ can you say a bit more about why you think it's Medium?

The attack that I was more worried about is as follows:

Consider the case where a host has some sort of endpoint (perhaps API) where the attacker has partial control over the content, but the rest of the content contains some sort of secret data. If the attacker could massage the output at the top to look like a valid SDCH dictionary header for the attacker controlled domain, they could then read the secret portion of the page using an AJAX request and serve up a page that is "compressed" against the malicious dictionary.

Note that as far as I can tell, there is no check to make sure the dictionary is served with the application/x-sdch-dictionary content type, so the content type of the target endpoint is irrelevant.

This is similar in concept to a Reflected File Download attack, and I don't think that it would be impractical to do in the wild.

But why does the dictionary fetch have privileges (to see the secret data) that a regular cross-origin fetch wouldn't?

Normally it would have to be explicitly allowed via CORS.

Ok, still digging (don't worry, I'm working on fixing this in the background, but I'd very much like to understand the threat model before I land).  

I agree that in the case where the attacker has partial control over the content and the rest of the content contains some sort of secret data that the attacker could get an arbitrary dictionary loaded.  However, that dictionary will be loaded for the target of the redirect, and hence will only be used when that target serves SDCH encoded content with the hash of the dictionary.  I think that is possible if the target site uses SDCH and the attacker can construct a dictionary with a hash matching a dictionary already in use on the site, but that seems contradictory to "part of the dictionary is secret content", which renders it hard to set the rest of the dictionary content to something that matches a particular hash.  What am I missing?

I was under the impression that the SDCH dictionary could get loaded for the /attacker/ domain, and the hash exposed through the Avail-Dictionary header.

Upon further inspection it seems that might not be true. https://code.google.com/p/chromium/codesearch#chromium/src/net/url_request/sdch_dictionary_fetcher.cc&rcl=1460474258&l=347 shows that the url passed into SdchOwner::OnDictionaryFetched is the URL from the result of the redirect, not the original dictionary target URL.

Sorry about that. I was only able to verify that the illegal cross-domain request was initiated (not that it shows in dev-tools...) before filing this bug. Seems my initial reading to understand the impact was incorrect, and the attacker can only bypass SdchDictionary::CanUse, not SdchDictionary::CanSet.

Err, I meant SdchManager::CanFetchDictionary is the one that can be bypassed, not SdchDictionary::CanUse.

*nod*  No worries; the SDCH code is squirrelly and the spec imprecise.  Thanks for working with me to get to the bottom of the threat model.

I'm going to drop the sec severity to low on the basis of our conversation; kenrb@, feel free to correct me.

This fix is being worked on (with discussion about appropriate changes) in https://codereview.chromium.org/1880283002/.

Is this solution kind of "curing headache with guillotine"? What about legitimate redirect from https://foo.example.com/sdch/dictionary-current to https://foo.example.com/sdch/<server_id>.dict. Or https://foo.example.com/sdch/dictionary-current to https://cdn.example.com/sdch/<server_id>.dict?

Isn't it better to apply actual CORS for dictionary fetches instead of blindly reject it?

The point is that the right way to fix it is by cleaning up the spec and making it more precise, which there's noone with time for at this end.  So this is a quick simple fix which solves the problem, unless it causes problems for content providers.  Thus my out of band email :-}.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a6980cd62b2118af7062163494c8a8bf5076ec20

commit a6980cd62b2118af7062163494c8a8bf5076ec20
Author: rdsmith <rdsmith@chromium.org>
Date: Tue Apr 19 19:04:30 2016

Disallowredirects in SDCH dictionary fetches.

BUG= 601234 
R=eroman@chromium.org

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

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

[modify] https://crrev.com/a6980cd62b2118af7062163494c8a8bf5076ec20/net/url_request/sdch_dictionary_fetcher.cc
[modify] https://crrev.com/a6980cd62b2118af7062163494c8a8bf5076ec20/net/url_request/sdch_dictionary_fetcher.h
[modify] https://crrev.com/a6980cd62b2118af7062163494c8a8bf5076ec20/net/url_request/sdch_dictionary_fetcher_unittest.cc
[modify] https://crrev.com/a6980cd62b2118af7062163494c8a8bf5076ec20/net/url_request/url_request.h

Now that this is merged into master, how long will it take until it is in chrome stable?

Looking at https://omahaproxy.appspot.com/, this appears to be in the 52 branch rather than the 51 branch.  Looking at http://dev.chromium.org/developers/calendar, that means mid-July.  If you'd like to make an argument that it should go in earlier, please feel free, but as discussed above I don't consider this a major security issue, and we don't like to merge changes to semi-stabilized branches unless it's high priority.

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

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

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