Can you explain the threat model where this is an issue?  Is it when unescaped attacker-controlled content is inserted into a cookie value? And if so, isn't escaping or otherwise encoding the content sufficient to protect from this? Seems like if a site is not, it has bigger issues like XSS.

Sure thing. Lets say a site implements html encoding thinking their safe. In most cases they would be, but since html encoding does result in extra semicolons then the scenario still plays out. 
The overall problem isn't the fact that malicious input can get their in the first place, it is that the default behavior of cookies magnifies the risk of malicious input ending up in cookies. just like adding gas to the fire, where as other browsers do not fan the flames.

Thank you for providing more feedback. Adding requester "nparker@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

In the scenario described thus far, an attacker with control of the cookie header may be able to potentially inject semicolons that cause cookie-limiting directives to be ignored. This, in combination with another vulnerability, might conceivably allow the attacker to see the content of the cookie into which they injected content.

This does not seem very interesting from a security POV. 

The number of cookie-controlling directives has risen over the years, with the comparatively recent addition of samesite and priority to the existing path/domain/expires/max-age/secure/httponly directives (and no change to kMaxPairs), but these should still be within the limit of 16 pairs.

I would have to disagree on the statement that this is not interesting from a security POV. By that logic a elevation of privilege is not interesting since you need some king of a foothold or initial privilege to begin with. Or is this a claim that being able to remove security flags from a cookie allowing attackers to modify or steal session information is not interesting?

For the last part it sounds like this is alluring to the natural occurrence of the vulnerability at hand. While it is true that if everyone sets cookies are is expected by specifically the chrome browser everything should be fine, the fact stands however that the web, developers, etc, are not perfect. Short of reading the chrome source code, web developer have no way of knowing that such consequences exists that if they go over a invisible limit. If i visit the same web page with multiple browsers, and only in the scenario of using a specific browser do i run into security problems, it would seem logical its a flaw in the that browser's implementation. 

If the stance is that this boils down to the fault of a web developer for writing insecure code in the first place, then why have any security protections in browsers at all and just put all the responsibility on developers and users. Why be arbitrarily selective in this case? 
The fact that there is malicious data in the cookie isn't the browsers fault. That may lead to possibly xss or such depending on how the cookie is used later, but again that is not the browsers fault. what is the browser fault is how they then process and act upon this data, its not simply passing it along, its acting on it. In this case base on possibly malicious data the browser will behave in a  insecure manner. How is this not a problem?

The bug isn't if cookie poisoning/injection is possible, its the fact that impact of such a scenario is amplified if you use chrome specifically vs a different browser. What can't be denied here is that fact. In such a scenario using chrome specifically puts you at more risk. 

This being said - please simply let me know if you will fix it or not. Yes or no, not if its interesting or not. I also intend to do a short write-up on this if that's a concern at all, just fair warning.

I'm marking this severity-low for now, but it might end up WontFix

+mkwst do you think it's worth addressing the 8-key/val-pair limit of cookies?

Modulo some renames and moves, we haven't touched `kMaxPairs` since the initial import of //net in 2008. I'm not opposed to removing that restriction, but I'd like to understand why it was put into place to begin with. Let's see if I can find more history internally...

The original commit (CL #4504394, for future spelunkers) has a comment noting that the author "added kMaxPairs, to limit the number of attributes we will try to parse". As that's all the justification I can find, and it doesn't look like Mozilla ever adopted a similar constraint, I wouldn't be terribly sad if we dropped it as well.

Just wanted to see if there was a official consensus on this?
Is this going to be fixed and if so whats the timeline on it?
I work for a security team at Microsoft and a official will fix or won't fix would be helpful for tracking on my end. I can't say i agree with a low severity rating since relating this to other vulnerabilities such a elevation of privilege wouldn't normally be rated as low. Looking as a comparable example again, if from guest or basic you and elevate to admin, that would be pretty severe. You wouldn't just say turn off the guest or basic account as a solution, you would fix the problem. In this case it's a predictable vulnerable behavior in a critical component allowing the bypass of expected security based behaviors/conditions. The likelihood is arguable, however the impact is high. 
That being said - just wanted to be crisp on my observed risk of this issue.

Overall hoping i can get some clarification on if this will be fixed and when.
Thanks

You can find Chrome's security vulnerability severity criteria defined here: https://www.chromium.org/developers/severity-guidelines

"elevation of privilege" is not the correct term of art here. The cookie header is the privileged resource, and it's expected that an attacker with control over the cookie header can control the behavior of cookies. The vulnerability in your scenario is in the website which has failed to protect its cookie header from injection.  If you work on a product which does not properly protect its cookies from injection, I encourage you to fix that product without regard to when or if Chrome decides to undertake a change here.

Thanks - 
In the severity criteria there is a timeline for critical bugs not nothing below critical as far as i can see. Are there any timelines around priority 3/low sev bugs?

In this example the attacker does not have to have full control of the cookie. All an attacker needs is a semicolon which is a character which is often seen as benign or valid and ends up in the result even after encoding depending on which encoding mechanism is chosen. The attacker need not even have to ensure that the malicious input is the last pair, and last is that which takes precedence. In the case of side by side tests of browsers, you would be completely safe with firefox and compromised with chrome. The vulnerability, again, here is not that injection is possible. It is that in this case, using chrome, you are more vulnerable. If you deal with enough web technology, you will see that semicolons are not strictly regulated as other special characters, hence the encoding example. Thanks for the recommendation of fixing products with injection vulnerabilities - however that is not the case. I reported this in the thought that here is a scenario where chrome can catch up to the security bar of other browsers and wanted to report this. The fact that i found it on the side while doing my work is the only reason i must track it accordingly. Its fine if we disagree on the risk, all i need here is ... if it will be fixed and when.

will this be fixed?
if so when?

I reported this a month ago, is there any consensus on 
- will this be fixed?
- if so when?
I think a month is a pretty generous timeline for a yes or no question. If i don't want me to publicly talk about this you have a week to let me know. otherwise with the lack of feedback ill just have to assume that no one cares about this and its not a problem.
Thanks  

Sorry. I think there were some crossed wires about who felt responsible for dealing with this bug.

It's a tiny change, I think the change is safe, and I'll just take care of it right now.

https://codereview.chromium.org/2876463006

Great - thank you

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

commit badf4bfd210beb80863554d5ddb8853b90124d06
Author: mkwst <mkwst@chromium.org>
Date: Mon May 15 10:49:13 2017

Allow an arbitrary number of cookie string pairs.

Currently, we limit cookie parsing to 16 attribute pairs. Other browsers
don't impose this limit, and we can increase interoperability (for weird
things like `a=b;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;secure`)
by dropping it. So, let's do so.

BUG= 711505 

Review-Url: https://codereview.chromium.org/2876463006
Cr-Commit-Position: refs/heads/master@{#471720}

[modify] https://crrev.com/badf4bfd210beb80863554d5ddb8853b90124d06/net/cookies/parsed_cookie.cc
[modify] https://crrev.com/badf4bfd210beb80863554d5ddb8853b90124d06/net/cookies/parsed_cookie.h
[modify] https://crrev.com/badf4bfd210beb80863554d5ddb8853b90124d06/net/cookies/parsed_cookie_unittest.cc

 Issue 532292  has been merged into this issue.

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