Windows Network File System flaw results in arbitrary code execution as SYSTEM
(2022/07/15)
- Reference: 1657894510
- News link: https://www.theregister.co.uk/2022/07/15/windows_nfs_patch/
- Source link:
Trend Micro Research has published an anatomy of a Windows remote code execution vulnerability lurking in the Network File System.
The vulnerability in question, CVE-2022-30136, was patched by Microsoft in June (you do keep your patches up to date, don't you?) but the research makes for interesting reading both in terms of the vulnerability itself and the potential for exploitation.
The vulnerability was contained within the Windows Network Filing System (NFS) and was due to improper handling of NFSv4 requests. It could be exploited by sending malicious RPC calls to a target server. Successful exploitation could result in arbitrary code execution as SYSTEM while unsuccessful exploitation could just crash the target.
[1]
The roots of NFS go right back to the work of Sun Microsystems in 1984 and the vulnerability existed in the Windows implementation. NFS uses Open Network Computing (ONC) Remote Procedure Call (RPC) to exchange control messages. The Windows vulnerability was "due to incorrect calculation of the size of response messages," [2]according to the researchers .
[3]
[4]
"The server calls the function Nfs4SvrXdrpGetEncodeOperationResultByteCount() to calculate the size of each opcode response, but it does not include the size of the opcode itself."
The result is a response buffer being too small and an overflow can result.
[5]
"Due to the function only being used for NFS version 4, only NFS4 is vulnerable," said Trend Micro.
[6]Lenovo issues firmware updates after UEFI vulnerabilities disclosed
[7]Microsoft's July Patch Tuesday fixes actively exploited bug
[8]Amazon squashes years-old authentication bugs in AWS Kubernetes service
[9]Older AMD, Intel chips vulnerable to data-leaking 'Retbleed' Spectre variant
Crafty attackers could use this vulnerability to fire off a request with enough operations to create a large size miscalculation. The execution of arbitrary code could be the result, or a simple crash of the system.
June's Patch Tuesday dealt with that other poster child of security holes, Follina, but CVE-2022-30136 looks to be relatively simple to exploit, certainly to the point where one could remotely crash a server.
[10]CVE-2022-30136 has now been patched (although you need to install the fix for another NFS RCE, [11]CVE-2022-26937 , first). Microsoft noted that the vulnerability did not exist in NFSv2 or v3 and suggested that an attack could be mitigated by disabling NFSv4.1.
However, as the Trend Micro Research Team commented, doing so "could lead to a loss of functionality."
[12]
"Applying both updates in the appropriate order is the best method to fully address these vulnerabilities."
A reminder that while Microsoft's patches might break things, the security implications of not applying them could be painful. ®
Get our [13]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YtGPHd@n1M3wcfGFmKTvYgAAABY&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://www.zerodayinitiative.com/blog/2022/7/13/cve-2022-30136-microsoft-windows-network-file-system-v4-remote-code-execution-vulnerability
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YtGPHd@n1M3wcfGFmKTvYgAAABY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YtGPHd@n1M3wcfGFmKTvYgAAABY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YtGPHd@n1M3wcfGFmKTvYgAAABY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://www.theregister.com/2022/07/14/lenovo_uefi_vuln/
[7] https://www.theregister.com/2022/07/12/microsoft_july_patch_tuesday/
[8] https://www.theregister.com/2022/07/12/authentication_bug_aws_kubernetes/
[9] https://www.theregister.com/2022/07/12/amd_intel_retbleed/
[10] https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-30136
[11] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26937
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YtGPHd@n1M3wcfGFmKTvYgAAABY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[13] https://whitepapers.theregister.com/
The vulnerability in question, CVE-2022-30136, was patched by Microsoft in June (you do keep your patches up to date, don't you?) but the research makes for interesting reading both in terms of the vulnerability itself and the potential for exploitation.
The vulnerability was contained within the Windows Network Filing System (NFS) and was due to improper handling of NFSv4 requests. It could be exploited by sending malicious RPC calls to a target server. Successful exploitation could result in arbitrary code execution as SYSTEM while unsuccessful exploitation could just crash the target.
[1]
The roots of NFS go right back to the work of Sun Microsystems in 1984 and the vulnerability existed in the Windows implementation. NFS uses Open Network Computing (ONC) Remote Procedure Call (RPC) to exchange control messages. The Windows vulnerability was "due to incorrect calculation of the size of response messages," [2]according to the researchers .
[3]
[4]
"The server calls the function Nfs4SvrXdrpGetEncodeOperationResultByteCount() to calculate the size of each opcode response, but it does not include the size of the opcode itself."
The result is a response buffer being too small and an overflow can result.
[5]
"Due to the function only being used for NFS version 4, only NFS4 is vulnerable," said Trend Micro.
[6]Lenovo issues firmware updates after UEFI vulnerabilities disclosed
[7]Microsoft's July Patch Tuesday fixes actively exploited bug
[8]Amazon squashes years-old authentication bugs in AWS Kubernetes service
[9]Older AMD, Intel chips vulnerable to data-leaking 'Retbleed' Spectre variant
Crafty attackers could use this vulnerability to fire off a request with enough operations to create a large size miscalculation. The execution of arbitrary code could be the result, or a simple crash of the system.
June's Patch Tuesday dealt with that other poster child of security holes, Follina, but CVE-2022-30136 looks to be relatively simple to exploit, certainly to the point where one could remotely crash a server.
[10]CVE-2022-30136 has now been patched (although you need to install the fix for another NFS RCE, [11]CVE-2022-26937 , first). Microsoft noted that the vulnerability did not exist in NFSv2 or v3 and suggested that an attack could be mitigated by disabling NFSv4.1.
However, as the Trend Micro Research Team commented, doing so "could lead to a loss of functionality."
[12]
"Applying both updates in the appropriate order is the best method to fully address these vulnerabilities."
A reminder that while Microsoft's patches might break things, the security implications of not applying them could be painful. ®
Get our [13]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YtGPHd@n1M3wcfGFmKTvYgAAABY&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://www.zerodayinitiative.com/blog/2022/7/13/cve-2022-30136-microsoft-windows-network-file-system-v4-remote-code-execution-vulnerability
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YtGPHd@n1M3wcfGFmKTvYgAAABY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YtGPHd@n1M3wcfGFmKTvYgAAABY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YtGPHd@n1M3wcfGFmKTvYgAAABY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://www.theregister.com/2022/07/14/lenovo_uefi_vuln/
[7] https://www.theregister.com/2022/07/12/microsoft_july_patch_tuesday/
[8] https://www.theregister.com/2022/07/12/authentication_bug_aws_kubernetes/
[9] https://www.theregister.com/2022/07/12/amd_intel_retbleed/
[10] https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-30136
[11] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26937
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YtGPHd@n1M3wcfGFmKTvYgAAABY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[13] https://whitepapers.theregister.com/
I used Windows NFS
simpfeld
But only to share Windows files out for Linux desktop users. So light usage. It was okay for this (maybe very okay), but the lack of reasonably handling of filename case issue would prevent me from doing anything deeper with it.
One thing was there is no group ownership file that you can set in the GUI even though this is stored in NTFS and used by their NFS. I had to write my own chgrp in PowerShell :(
Would have been easier if they had just exposed the NFSv4 ACL's mapped from NTFS ACL's (they are pretty identical), but they only map ACL entries for owner, group and other (everyone on NTFS) to basic unix perms. Hence the need for a chgrp.
Windows NFS was so terrible
Maybe it's better now but am not holding my breath. Several years ago I tried to deploy a pair of "appliances" from HPE that ran Windows 2012 Storage server specifically for NFSv3 for Linux clients (and maybe 1% SMB). I chose this because it was supported by HPE, it could leverage existing back end SAN for storage, and it was highly available. Add to that I only needed maybe at most 3TB of space so buying a full blown enterprise NAS was super overkill as nobody made such small systems. SMB NAS units(Synology etc) I didn't deem acceptable levels of high availability.
I figured my use case is super simple(file storage, not transactional storage), my data set is very small, my I/O workload is pretty tiny, it's fully supported so how hard could it be for Windows to fill this role?
Anyway, aside from the 9 hour phone support call I had to sit on while HPE support tried to get through their own quickstart guide (I was expecting a ~10 minute self setup process) due to bugs or whatever(they ended up doing manual registry entries to get the two nodes to see each other which were connected directly via ethernet cable), the system had endless problems from a software perspective. 99% of the software was Microsoft, the only HPE stuff was just some basic utilities which for the most part I don't think I even used outside of the initial setup.
I filed so many support issues, at one point HPE got Microsoft to make a custom patch for me for one of the issues. I never deployed the patch purely out of fear that I was the only one in the world to have the issue in question(that and it wasn't my most pressing concern of all the problems I was having). I should of returned the systems right away but I was confident I could work through the problems given time. I had no idea what I was in for when I made that decision. I was also in periodic contact with HPE back end engineering for this product though their resources were limited as the software was all Microsoft.
The systems never made it past testing, maybe 6 months of usage with many problems and support cases and workarounds and blah blah.. I designed the file system layout similar to our past NAS offerings from Nexenta(VM based), and FreeNAS (also VM based). There were 5 different drive letters, one for production, one for staging, one for nonproduction, one for backups(with dedupe enabled) and one for admin/operations data. The idea is if there is a problem on one of those it doesn't impact the others.
The nail in the coffin for this solution for me, was at one point the backups volume (which had dedupe enabled) gave an error saying it was out of space(when it had plenty of space according to the drive letter and according to the SAN). When this happened the entire cluster went down(including the other 4 drive letters!). The system tried to fail over but the same condition existed on the other node. I had expected that just that one drive letter/volume to fail, that is fine let the others continue to operate. But that's not what really happened, all data went offline. I worked around the issue by expanding the volume on the SAN and it cured it for a while, until it happened again, all volumes down because one got full. WTF.
I tried to figure out a way to configure the cluster so that it would continue to operate the other 4 drive letters while this one was down. Could not figure it out(and didn't want to/couldn't wait hours for support to try to figure it out). So I nuked the cluster. Went single node, from that point on if that drive letter failed(if I recall right anyway this was years ago) the other drives remained online. I assume the source of the "out of space" error was some bug or integration issue with thin provisioning on the SAN, but was never able to figure it out. I do recall getting a similar error from our FreeNAS from the same array, there was plenty of space but FreeNAS said there was not(filesystem was 50% full). This issue ONLY appeared on volumes with dedupe enabled (Windows side dedupe, and FreeNAS side dedupe). I've never seen that error before or since. It was an old array so maybe the array's fault. I don't mind that particular volume going offline (it only stored backups), but the final straw was that volume being offline should not of taken the rest of the system down(in the case of Windows cluster) with it.
But I had so many other annoying issues with NFS on Windows, I'm a Linux person so I didn't have high expectations for awesome NFS from Windows but again my use case was really light and trivial(biggest requirement was high availability).
In the end I migrated off of that Windows NFS back to FreeNAS again(had replication but no HA, so I never applied any OS updates to the system while it was in use, fortunately no failures either), before later migrating to Isilon. Makes me feel strange having 8U of Isilon equipment for ~12TB of written data(probably be closer to 7TB after Isilon overhead, more data than original because years have passed and we have since grown). But I was unable(at the time) to find a viable supportable HA NAS head unit offering to leverage shared back end storage. I was planning on going NetApp V-series before I realized the cost of Isilon was a lot less than I expected(and much less than V-Series for me at the time especially if you consider NetApp licensing for both NFS and SMB).
(When I first started out we used Nexenta's VM based system, and they officially supported high availability running on VMs. Initially this worked fine, however in production it was a disaster as the Nexenta systems went split brain on several occasions corrupting data in ZFS(support's only response was "restore from backups"), things were fine after destroying the cluster and going single node but of course no HA anymore)