Microsoft released CVE-2020-1045 in September 2020.

A security feature bypass vulnerability exists in the way Microsoft ASP.NET Core parses encoded cookie names.

The ASP.NET Core cookie parser decodes entire cookie strings which could allow a malicious attacker to set a second cookie with the name being percent encoded.

The security update addresses the vulnerability by fixing the way the ASP.NET Core cookie parser handles encoded names.

The only way to mitigate this vulnerability is to update the .net core version of every application. They suggest 3.1 but the small print also suggests any thing higher than 2.1.21 will work.

The question on my mind though, is whether this vulnerability is actually exploitable.

It mentions that an attacker may be able to "bypass certain security restrictions" - but since an HTTP request can contain any cookie it wants, I can't see how the CVE changes anything. Its possible that for "security reasons" one or more Microsoft libraries refused to honour certain cookies based on their name by stripping them from the request header. Do any libraries use "secret cookies" which aren't supposed to be set by the user? If so, how are the values actually set?

Basic questions:

  1. What kind of attack can I actually perform by creating additional cookies through this vulnerability, rather than using a Set-Cookie header? For example, is there possibly a privilege escalation attack?
  2. What security restrictions can be bypassed? Are they referring to security restrictions in related MS Libraries, or in third party libraries, or something else?
  3. Is there anything an attacker can do with this vulnerability that they cannot do with a normal Set-Cookie header? Even in theory?
  • Supposedly there's a PoC, but I couldn't find it yet.
    – MechMK1
    Jan 13 at 14:50
  • It looks like you are asking for details that are simply not available or disclosed. Your questions are valid, but it appears that the answers are not available.
    – schroeder
    Jan 13 at 14:57
  • You are left with, as we all often are, incomplete knowledge and a CVSS rating that is forcing us to respond. And in such cases, you can either go through the work to validate the risks, or blindly trust the rating and respond as the rating suggests. Neither situation is ideal.
    – schroeder
    Jan 13 at 15:00
  • There may be something I have not considered. For example, if there was a vulnerability where I could modify HTTP only cookies from javascript, I would be able to exploit this without any further information. Is there anything like that in this CVE which I have not thought of? Jan 13 at 15:00
  • I'm inclined to ignore this, since it appears to have a strict subset of the capabilities of the Set-Cookie header - which is under the full control of anybody sending a request. Jan 13 at 15:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.