Quick summary: There has been relatively little news after the vulnerability was released. I think a couple of things are happening: (1) This is a relatively straightforward Windows patch. Unlike for example log4j, inventory is less of an issue here. Enterprises tend to have a reasonably good handle on patching Windows. (2) Just like prior http.sys vulnerabilities, this one is likely not that easy to exploit. We will see what happens and there could still be a surprise out there. So keep patching. There is one unverified exploit claim so far.

I removed the "work in progress" disclaimer from this post. We will likely publish a new post if something should substantially change. Also check Microsoft original advisory for updates: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21907

1 - When will an exploit be available?

Who knows. Microsoft rates the exploitability as "Exploitation More Likely." I suggest you patch this week. On Wednesday evening, a possible exploit was released but only as an encrypted file on GitHub and it is impossible to ascertain if the exploit is real or fake (see comment left by a reader below. BEWARE OF RUNNING EXPLOITS FROM UNKNOWN SOURCES.

2 - Which versions are affected?

(note only supported versions are covered)

Not Vulnerable By Default: Windows Server 2019, Windows 10 Version 1809. These versions are only vulnerable if HTTP trailer support is enabled via the EnableTrailerSupport registry value (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters). By default, this key is not defined. It has to be set to a value other than 0 to enable trailer support. 

Vulnerable by default:

• Windows 10 20H2, 21H1, 21H2 
• Windows 11
• Windows Server 2022, 20H2

Not Vulnerable:

• Windows 10 1909

 (thanks @hetrogjanr and @wdormann). 

You can check this registry value in Powershell. But remember it is not set by default. (thanks, Rob): 

Get-ItemProperty  "HKLM:\System\CurrentControlSet\Services\HTTP\Parameters" | Select-Object EnableTrailerSupport

Windows Server 2019 and Windows 10 version 1809 are not vulnerable if the key is not set, or if it is set to 0. The key doesn't matter for other versions of windows.

3 - Am I vulnerable if I do not have IIS enabled?

Possibly. This is NOT an IIS vulnerability, but a vulnerability in http.sys. http.sys is probably best described as the core HTTP/.Net engine used by IIS and other software. But other software using http.sys and possibly exposing the vulnerability: WinRM (Windows Remote Management), WSDAPI (Web Services for Devices) for example, expose http.sys. For a quick list of processes using http.sys, try:

netsh http show servicestate

4 - What is an attacker able to do with this vulnerability?

Microsoft implemented http.sys as a kernel-mode driver. In other words: Running code via http.sys can lead to a complete system compromise. However, past vulnerabilities (for example, CVE-2021-31166) were never fully exploited as several techniques were used to mitigate exploitation, and PoCs released were only able to cause a denial of service. The CVSS 3.1 base score for the vulnerability is 9.8 out of 10.

5 - Does a web application Firewall help?

Likely yes. You could start (at your own risk) to block requests with trailers. Maybe log them first to see if you see legitimate uses (let us know what uses them and how). For details, ask your web app firewall vendor.

6 - Was there a similar severe vulnerability in the past?

In 2015, we had a similar fire drill for CVE-2015-1635 (MS15-34). Maybe you kept notes? They will come in handy now. This Range header vulnerability never amounted to much.

7 - What are these Trailers about anyway?

Trailers are defined in RFC7230. They only make sense if "Transfer-Encoding: chunked" is used. With chunked encoding, the body of a request or response is transmitted in small chunks. A length precedes each chunk in bytes. The idea behind this is that you may not know how long it will be as you start sending a message. In addition, chunked encoding does allow the sender to delay sending headers until the body is sent. These become "trailers." Here is a quick sample request:

POST / HTTP/1.1
Host: testing
Content-Type: text/plain
Transfer-Encoding: chunked
Trailer: X-Test

3
ABC
0
X-Test: 123

The RFC states that "the sender SHOULD generate a Trailer header," suggesting it is not mandatory. This may complicate filtering if an exploit does not use a Trailer header (again: I am speculating what an exploit may look like, but having a trailer without a corresponding trailer header may cause some confusion).

For responses, http.sys only supports trailers for http/2. I haven't found any documentation for requests yet.

8 - Will we go to Infocon Yellow again?

Once we see exploitation of this vulnerability.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|