fortra/cve-2022-30136Windows Network File System Remote exploit for CVE-2022-30136
author: Ricardo Narvaja
For demonstration purposes only. Complete exploit works on vulnerable Windows Server systems.
Checkout the writeup Analysis of CVE-2022-30136 “Windows Network File System Vulnerability“.
I wanted to write this article to demonstrate the analysis I did while developing the Core Impact exploit “Windows Network File System Remote” that abuses the CVE-2022-30136 vulnerability.
The Windows Network File System Remote Code Execution vulnerability is a size calculation error that occurs when creating the server response in a COMPOUND REQUEST using version 4.1 of NFS.
The server calculates a smaller size than necessary to allocate the pool, and then, when copying the data to generate the response, overflows the buffer.
The function Nfs4SvrXdrpGetEncodeOperationResultByteCount in nfssvr.sys is called for each operation and returns a size that is smaller than necessary (4 bytes less for each operation).
A patch was made for Nfs4SvrXdrpGetEncodeOperationResultByteCount.
This function is called during each OPERATION of a COMPOSE REQUEST so that it returns the bytes needed for each of them based on the OPCODE. It is then added to the header and other parts of the response. Next, it calculates the final size of the entire response to allocate and then copies on it to reply.
In each case, we can see that the value of the size returned for each operation is four bytes smaller in the vulnerable version than the patched version.
I build the POC for Windows server 2019.
Below is the vulnerable version of nfssvr.sys used for this POC, followed by the patched version for Windows server 2019:
The next image shows CASE 26 in the diff:
In the example of CASE 26, we can see that the constant added to the calculated value is 0x2c in the vulnerable version, and 0x30 in the patched version.
The same can be seen in each case corresponding to each OPCODE. The vulnerable one always returns a size four bytes smaller than the patched one.
We are not going to show all the cases because the patch is similar for all OPCODES.
The parent of Nfs4SvrXdrpGetEncodeOperationResultByteCount is Nfs4SvrXdrEncodeCompoundResults. It reads the number of operations sent in the COMPOUND REQUEST.
In this POC the value is 0x34 (52d). When my POC connects to the server to the port 2049 (the default port to NFS), I need to place a conditional breakpoint for a stop.
In this instance, it stops when number_of_operations=0x34.
The pool with tag ARGS is allocated here.
I will then create a structure named TAG_ARGS_0x10e0 to reverse the fields.
It copies the number_of_operations into r13 and loops into the vulnerable function once per operation, until the counter reaches the value of r13.
It shows that the first package_OPCODE= 0x35, which corresponds to SEQUENCE in the first mandatory operation in a COMPOUND REQUEST. In the image below, the arrow points to this OPCODE in my package.
Here we can see the arguments of the vulnerable function.
Inside the vulnerable function it reads the OPCODE and goes to the corresponding CASE.
Three is subtracted from the original OPCODE value (53).
And jumps to CASE 50, returning 0x28 to the necessary size for this operation.
We can see in the diff how the patched version returns 0x2c.
This returned value is added to the previous value of other fields in the response in order to calculate the size of the operations. In this case, this value is 0X40c.
Below we can see the values being added:
When it exits the loop, the total size is calculated. In this case, the total size is 0x1310.
We can guess the difference between the vulnerable version and the patched version by calculating the size, using the formula: number_of_operations * 4.
In this case the allocation in the patched version will be 0x34 * 4 = 0x68 bigger than the vulnerable version.
After that it adds 0x24. This value is calculated in similar way in both vulnerable and patched versions.
It then adds the constant 0xf in both cases.
Up to this point, the size in this example has been 0x1340.
Next it reaches rpcxdr_OncRpcBufMgrpAllocate.
It then moves to r15.
