An uninitalized “Fast Tracker” in the Window’s HTTP Protocol stack as used by IIS. Despite providing a bit of a crash analysis and a POC the post is missing information about the vulnerability as their primary focus was on building out the exploit.
We start in
HTTP!UlFastSendHttpResponse which is used to send an HTTP Response. When the originating request includes the
TE: trailers header the function will allocate a “Fast Tracker” with a call to
UlpAllocateFastTracker. There is only an uninitialized use when the HTTP version is missing from the request line so presumably it was performing some conditional initialization there and when the version failed to match the usual suspects like
HTTP/2 the value was just never initialized.
It is perhaps worth calling out that the
TE: header is important because it indicates the transfer encodings the client will accept. In
HTTP/1.1 there are several options for this, but in
HTTP/2 the only acceptable value is
trailers. So there is the chance that there is some sort of HTTP version confusion going on also.
With an uninitialized “Fast Tracker” and control over the contents through heap spraying with other requests they could gain control over the argument to a
MmUnmapLockedPages call. Resulting in a page fault with a bad pointer and a denial of service attack. Which is perhaps a useful primitive for a more complex chain abusing this for a sort of use-after-free situation although I’m not familiar enough with the Windows Kernel to comment on the nuances of
MmUnmapLockedPages for such a use.