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 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 24
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug-Security


Participants' hotlists:
Hotlist-1


Sign in to add a comment

Security: Fetch API reveals existence of Redirection in no-cors mode

Reported by ahsaneja...@gmail.com, Dec 3 2017

Issue description

This template is ONLY for reporting security bugs. If you are reporting a
Download Protection Bypass bug, please use the "Security - Download
Protection" template. For all other reports, please use a different
template.

Please READ THIS FAQ before filing a bug: https://chromium.googlesource.com
/chromium/src/+/master/docs/security/faq.md

Please see the following link for instructions on filing security bugs:
https://www.chromium.org/Home/chromium-security/reporting-security-bugs

NOTE: Security bugs are normally made public once a fix has been widely
deployed.

VULNERABILITY DETAILS
Fetch API can detect if the request is redirected even when in fetch mode "no-cors". If the request mode is set to opaque, this information should not be determinable. 

VERSION
Chrome Version: latest stable 
Operating System: Windows 10

REPRODUCTION CASE
I do not own the website. When using fetch api in "no-cors" mode the response is set to opaque. Which means no information about if the request is redirected should be revealed. 

//Normal, correct behaviour, works fine
fetch("https://jigsaw.w3.org/HTTP/300/307.html", {
  mode: 'no-cors'
}).then(function (response) {
  if (response.redirected) {
    console.log("Redirected")
  } else {}
  return response.blob()
}).then(function (imageBlob) {
  console.log("Found")
}).catch(function () {
  console.log("Error request blocked.")
})

//Limitation bypass
fetch("https://jigsaw.w3.org/HTTP/300/307.html", {
  mode: 'no-cors',
  redirect: "error"
}).then(function (response) {
  return response.blob()
}).then(function (imageBlob) {
  console.log("Downloaded")
}).catch(function () {
  console.log("Redirected or Error")
})

 
Cc: horo@chromium.org
Components: Blink>Network>FetchAPI
Labels: OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Mac OS-Windows
Summary: Security: Fetch API reveals existence of Redirection in no-cors mode (was: Security: Fetch API redirected information in no-cors mode bypass)
At first glance, this looks like a spec issue to me; I don't see anything in https://fetch.spec.whatwg.org/#concept-request-redirect-mode that implies something different should happen in the case of |redirect: "error"| for a no-cors request.

Comment 2 Deleted

Cc: -horo@chromium.org tyoshino@chromium.org
Labels: ReleaseBlock-Stable M-62
Owner: horo@chromium.org
Status: Assigned (was: Unconfirmed)
horo: could you please help triage? Thanks!
Cc: hirosh...@chromium.org mkwst@chromium.org annevank...@gmail.com yhirano@chromium.org
Labels: -ReleaseBlock-Stable Security_Impact-Stable
Sorry I meant to be Impact stable rather than RBS
elawrence@ is right, I think. "Main fetch" has a step to taint a response, but it happens only when the response obtained by the step 5 is not a network error. "Scheme fetch" returns a network error returned by "HTTP fetch".

Looks SRI has the same issue though SRI is specified to run "match" on a tainted response which may just always fail.

That said, it looks it's been already discussed. horo@ should be familiar with the details.
https://github.com/whatwg/fetch/issues/79

Comment 7 by horo@chromium.org, Dec 4 2017

Cc: evn@google.com bke...@mozilla.com
I think this is a spec issue.
The same problem exists in all other major browsers (Safari, FireFox and Edge).

I think https://github.com/whatwg/fetch/issues/79 is different from this issue.
That fetch spec  issue 79  was to protect a web site which is using service worker and redirection from XSS attack.

But this issue is not related to service worker.
For example you can detect whether the web site visitor is an Gmail user or not using this code:
  fetch("https://mail.google.com/mail/u/0/", {
    mode: 'no-cors',
    redirect: 'error',
    credentials: 'include'
  })
  .then(() => {
    console.log('GMail user');
  }).catch(() => {
    console.log('Not GMail user');
  });


annevk@
What do you think?
It seems this was introduced in https://github.com/whatwg/fetch/issues/66#issuecomment-118638144.

My analysis there seems correct, but the fix didn't restrict things to same-origin requests unfortunately. (We were much worse about enforcing review for pull requests back then unfortunately, although those are still hard to come by. Getting more security on all things service workers touched would be good.)

I think the correct fix here would be enforcing that request's mode is "navigate", "websocket", or "same-origin". That should be an assert somewhere in the fetching and algorithm. If request's mode is something else a TypeError seems appropriate in the API (the Request constructor).

Does that help? I can work on more detailed proposed changes to be made after this and equivalent bugs against other browsers are opened up if that's desirable.

Did OP file an equivalent bug against Firefox? (And maybe Edge/Safari, they shipped this too I guess even though they don't have service workers?)

Comment 9 Deleted

ahsanejaz26, please copy me (I'm annevk@annevk.nl) if you can. I'd like to make sure we all end up with the same fix.
I have filed for Firefox and Edge. 

Comment 12 Deleted

Someone needs to file for Safari
Cc: dved...@mozilla.com

Comment 17 by horo@chromium.org, Dec 4 2017

Thank you for filing bugs.
I think checking the request's mode looks good.

Labels: Security_Severity-Low
In my mind it's unclear what kind of attacks this could be used for and thus what the severity should be. Tentatively assigning low severity, but horo or others, could you please outline the risks involved with this bug?
The risk is that you can more easily determine whether a user has an account with a given site (assuming the site offers credential-based redirects, which is quite common). However, a determined attacker is likely also able to figure this out through timing attacks.

Comment 20 Deleted

Project Member

Comment 21 by sheriffbot@chromium.org, Dec 5 2017

Labels: Pri-2
In https://bugzilla.mozilla.org/show_bug.cgi?id=1422710#c5 Ben suggested to instead return a network error by modifying step 5 in https://fetch.spec.whatwg.org/#main-fetch as follows:

* request’s mode is "no-cors" 
  1. If request's redirect mode is "error" return a NetworkError.
  2. Set request’s response tainting to "opaque".
  3. Return the result of performing a scheme fetch using request.

I think that would work and would less likely break existing code that does not expect an exception. I would only suggest to also check (and therefore block) "manual" as otherwise we make timing attacks rather easy.
Cc: youe...@gmail.com

Comment 24 by horo@chromium.org, Dec 7 2017

Cc: horo@chromium.org
Owner: tyoshino@chromium.org
Reassigning to tyoshino@
Project Member

Comment 25 by sheriffbot@chromium.org, Dec 7 2017

Labels: -M-62 M-63
Project Member

Comment 26 by sheriffbot@chromium.org, Jan 25 2018

Labels: -M-63 M-64
Project Member

Comment 27 by sheriffbot@chromium.org, Mar 7

Labels: -M-64 M-65
Owner: ----
Is someone planning on fixing this? I'm planning on updating the specification. Since WebKit already published tests I guess this attack is already publicly known, but it would still be nice not to spread the knowledge further without fixes having landed.

(Removing Owner as tyoshino left.)
Status: Available (was: Assigned)
Owner: yhirano@chromium.org
Status: Assigned (was: Available)
Yeah, I was confused and we already made the change. My bad.
Project Member

Comment 33 by sheriffbot@chromium.org, Apr 18

Labels: -M-65 M-66
Please be aware that I think the upstream test that landed today does not match what landed in the spec.  I'm working on a PR to update the test and will share it here when its ready.
Status: Fixed (was: Assigned)
Project Member

Comment 38 by sheriffbot@chromium.org, Apr 24

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-topanel
Labels: -reward-topanel reward-unpaid reward-500
*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
*********************************
Cc: awhalley@chromium.org
Thanks for the report ahsanejaz26@ - the VRP panel decided to award $500 for this! A member of our finance team will be in touch to arrange for payment. Also, how would you like to be credited in the Chrome release notes?
Labels: -reward-unpaid reward-inprocess
Hi,
Thanks a lot for the reward! 
Crediting like this would be fine "AhsanEjaz - @AhsanEjazA".
Hi,
One more thing, the bug has been disclosed to Webkit and Mozilla already, after Chromium, as stated in early comments of the thread. The fix for Webkit is there, and they assigned it CVE-2018-4117, for their products. https://nvd.nist.gov/vuln/detail/CVE-2018-4117 . I'm not sure if Mozilla and Webkit are "third parties who are not directly involved in fixing the bug" or not.
ahsanejaz26@ - thanks for hilighting that, but it wont' be a problem for the VRP payment
Issue 834895 has been merged into this issue.
Labels: -M-66 M-68
Labels: CVE-2018-4117 Release-0-M68
Project Member

Comment 49 by sheriffbot@chromium.org, Jul 31

Labels: -Restrict-View-SecurityNotify allpublic
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

Sign in to add a comment