Update: There appears to be some initial patch analysis on this vulnerability at https://piffd0s.medium.com/patch-diffing-cve-2022-21907-b739f4108eee which seems to suggest the patched functions are UlFastSendHttpResponse, UlpAllocateFastTracker UlpFastSendCompleteWorker, UlpFreeFastTracker, and UlAllocateFastTrackerToLookaside. They also note that based on their analysis a safe assumption may be that the vulnerable code path is hit first in UlFastSendHttpResponse and some of the fixup / mitigations were applied to memory chunks in the other functions. Analysis is still ongoing though.

There has been a lot of confusion r.e this vulnerability, which is a RCE in the HTTP Trailer Support feature of the http.sys component which is responsible for the HTTP Protocol stack used by several high privileged Windows components. The best writeup I was able to find was at https://isc.sans.edu/diary/28234 however note that investigation is still ongoing and its likely that things will change over time.

First off, to be clear, despite http.sys appearing to be associated with IIS, this is not in itself an IIS vulnerability. As noted at https://isc.sans.edu/diary/28234, you can find which components are using http.sys by running the command netsh http show servicestate. You’ll likely find more components using it then you thought, for example Intel components use this for some odd built in HTTP server (yeah I’m not sure either but there you go).

Secondly, whilst the vulnerability affects Windows 10 1809 and Windows Server 2019 and later, by default, and only on Windows 10 1809 and Windows Serve r 2019, HKLM:\System\CurrentControlSet\Services\HTTP\Parameter\EnableTrailerSupport is set to 0 by default, thus disabling the vulnerable trailers feature. This means these versions are not vulnerable out of the box, however if the HKLM:\System\CurrentControlSet\Services\HTTP\Parameter\EnableTrailerSupport registry key is set to 1 then they are. All other affected versions of Windows are vulnerable using their default settings.

As this is a kernel level vulnerability and it being exploited remotely I imagine now would be a good time to remind people that RCE bugs in the Windows kernel have become increasingly hard to exploit. Whilst Windows 7 was easier to exploit due to lack of a number of mitigations, with Windows 10 and Windows 11, several mitigations have been implemented into the Windows kernel specifically to prevent RCE kernel exploits and from my experience they work very well to this effect (local privilege escalation attacks are another story which still needs improvement though).

Finally as for those wondering what Trailer support is anyway (like myself), https://isc.sans.edu/diary/28234 notes that RFC7230 specifies the protocol for trailer support, noting that it only makes sense if Transfer-Encoding: chunked is used in a request to a server. This allows a requestor to essentially chunk the request up into several smaller packets and then only send the headers for the request after the request body has been sent. The original idea behind this was that the request body may be generated over time and we want to start sending data as it becomes available to speed things up and ensure quicker operations.

Hopefully that helps, still not a lot of detail on this right now and there will likely need to be some patch diffing going on before people are able to better determine the root cause of this issue, but for now I’d say patch if you can whilst also keeping in mind a working exploit will likely take time to develop if its possible given Microsoft’s kernel level mitigations for Windows 10.