New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 431504 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jan 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security
Nag



Sign in to add a comment

Security: Cookie injection by Proxy with 407 response

Reported by ili...@gmail.com, Nov 8 2014

Issue description

Chrome mistakenly accepts cookies in a 407 response of CONNECT request from proxy.

VERSION
Chrome Version: All
Operating System: All

REPRODUCTION CASE
1. Set up a HTTP proxy in Chrome.
2. Navigate to https://mail.google.com.
    Chrome actually sends a CONNECT request:
        CONNECT mail.google.com:443 HTTP/1.1
	Host: mail.google.com
3. The proxy responds a 407 message, including Set-Cookie headers.
        HTTP/1.1 407 Proxy Authentication Required
        Proxy-Authenticate: Basic realm=”auth"
        Set-Cookie: SID=malicious; domain=.mail.google.com; path=/; SECURE;
4. Chrome mistakenly accepts the malicious cookies.

 

Comment 1 by tarqui...@opera.com, Nov 10 2014

This appears to be a duplicate of  bug #137891 , which is already marked as fixed as of 2012.

Comment 2 by ili...@gmail.com, Nov 10 2014

It seems that Chrome rejects all error responses to CONNECT requests, except 407. I test it in all platforms (Windows, OS X, Linux, Android, iOS). 

Android WebView is also affected. Especially, in WebView, the Proxy-Authenticate header is not required, it means that cookies will be injected silently.

Comment 3 by tarqui...@opera.com, Nov 10 2014

Labels: Cr-Internals Cr-Internals-Network Cr-Internals-Network-Proxy

Comment 4 by tarqui...@opera.com, Nov 10 2014

Status: Untriaged
Reproduced in 40.0.2202.3 dev-m Win, using Fiddler to intercept the CONNECT and replace it with an appropriate response.
Cc: ttuttle@chromium.org
Cc: -ttuttle@chromium.org
Owner: ttuttle@chromium.org
Status: Assigned
Labels: Security_Severity-Medium Security_Impact-Stable
Labels: M-40
Project Member

Comment 9 by ClusterFuzz, Nov 12 2014

Labels: Pri-1
Project Member

Comment 10 by ClusterFuzz, Nov 18 2014

Labels: Nag
ttuttle@: Uh oh! This issue is still open and hasn't been updated in the last 7 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz
Project Member

Comment 11 by ClusterFuzz, Nov 25 2014

ttuttle@: Uh oh! This issue is still open and hasn't been updated in the last 7 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz
Cc: rsleevi@chromium.org
Cc: rch@chromium.org

Comment 14 by rch@chromium.org, Dec 2 2014

Cc: asanka@chromium.org
+asanka
ttuttle: Do you plan to fix this? I'm assuming it's a straightforward issue of stripping cookie header in a 407 response to a CONNECT?
I'm working on it right now, but in the codereview, folks want me to whitelist headers instead of blacklisting, and that breaks a bunch of tests (e.g. ones that expect to be able to receive the response).
OK, thanks for the update.
Project Member

Comment 18 by ClusterFuzz, Dec 13 2014

ttuttle@: Uh oh! This issue is still open and hasn't been updated in the last 7 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz
ttuttle: You mentioned that you had an outstanding CL for this. Is it
still in the works?
ttuttle@chromium.org, friendly ping.
Project Member

Comment 21 by ClusterFuzz, Jan 4 2015

ttuttle@: Uh oh! This issue is still open and hasn't been updated in the last 28 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz
Labels: OS-All
Project Member

Comment 24 by ClusterFuzz, Jan 25 2015

ttuttle@: Uh oh! This issue is still open and hasn't been updated in the last 49 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz
Status: Fixed
Please don't forget to mark bug as FIxed :)
Labels: reward-topanel
Project Member

Comment 27 by ClusterFuzz, Jan 26 2015

Labels: -Restrict-View-SecurityTeam Merge-Triage M-41 Restrict-View-SecurityNotify
Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Requested label.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on omahaproxy.appspot.com.

- Your friendly ClusterFuzz
Cc: timwillis@chromium.org
Labels: -M-40 -Merge-Triage Merge-Requested
Merge requested to M41 (branch 2272)
Labels: -Merge-Requested Merge-Review Hotlist-Merge-Review
[Automated comment] Less than 2 weeks to go before stable on M41, manual review required.
Labels: -Merge-Review -Hotlist-Merge-Review Merge-Approved
Merge approved for M41 branch 2272.
Note: M41 stable cut happens in days, and you're approved for merge.  Get it in there!  (Let me know if you need any help, or aren't confident.)
ttuttle: please merge this to M41 (branch 2272).
Eek, sorry, will do.
...just tried to cherry-pick this onto 2272, and it says the resulting commit is empty. It looks like it already made it onto that branch when it originally landed.
Labels: -Merge-Approved
Yup, it's in there.  No merge required, thank you.
Labels: Release-0-M41
Labels: -reward-topanel reward-500 reward-unpaid
Congratulations - $500 for this report.

Notes from reward panel: It seems it's already possible to do cookie forcing for sites that are exclusively HTTPS with HSTS, you just need a single HTTP request to _any_ origin. This particular attack also requires a non-default config. That said, the panel felt that because we made a change to this behavior and considering the severity of the issue, a reward of $500 was appropriate.

You'll be credited in the release notes as "iliwoy" - please let me know if you'd like to use a different name ASAP.

Someone from our finance team will get in contact with you in the next week or two to collect your details to arrange payment. If you don't hear from them, please either update this bug or contact me directly.

A CVE will also be assigned to this bug for your reference - stay tuned.
Labels: CVE-2015-1229
Assigning CVE.
Labels: -reward-unpaid reward-inprocess

Comment 40 Deleted

Project Member

Comment 41 by ClusterFuzz, May 4 2015

Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Labels: -reward-inprocess
Processing via our e-payment system can take up to two weeks, but the reward should be on its way to you. Thanks again for your help!
Owner: juliatut...@chromium.org
Project Member

Comment 44 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 45 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
Labels: CVE_description-submitted

Sign in to add a comment