RPC Runtime, Take Two: Discovering a New Vulnerability
Written by: Ben Barnea
Executive Summary
Akamai researcher Ben Barnea found an important vulnerability in the Remote Procedure Call (RPC) runtime library: CVE-2022-22019, with a base score of 8.8.
The new vulnerability takes advantage of an integer overflow that was previously reported to Microsoft and patched in April 2022.
The new vulnerability has been addressed in Microsoft’s May Patch Tuesday.
We recommend, alongside Microsoft’s previous list of mitigations, to patch swiftly and leverage network segmentation to limit the exploitation of these vulnerabilities for lateral movement.
Introduction
On April 12, 2022, Microsoft released patches for three vulnerabilities in the Remote Procedure Call (RPC) runtime library (rpcrt4.dll). These vulnerabilities were assigned the following CVEs: CVE-2022-26809, CVE-2022-24492 and CVE-2022-24528. Affected operating systems are Windows 7, 8, 10, and 11, and Windows Servers 2008, 2012, 2019, and 2022.
Exploiting these vulnerabilities would allow a remote, unauthenticated attacker to execute code on the vulnerable machine with the privileges of the RPC service. This capability can be used both to breach a network and perform lateral movement, and is therefore desired by attackers and ransomware operators. Microsoft, on their part, marked these vulnerabilities as likely to be exploited. Due to their severity (CVSS 9.8), we decided to take an in-depth look at the patched library and wrote about our findings in a previous blog post on the subject.
We found that two of the vulnerabilities were integer overflows, and that the patch was adding a check to see if an integer overflow had occurred. This fix allowed Microsoft to prevent exploitation of those particular vulnerabilities. However, during our investigation we were able to find an additional vulnerability utilizing integer overflow of the same variable as was previously discovered; which was not mitigated by the added check.
After a responsible disclosure process with Microsoft, we can now outline the new RPC vulnerability. It was discovered the day April’s Patch Tuesday was released, and has now been addressed in May’s patch. The vulnerability, which is present both in server and client code, was assigned a single CVE:
Understanding the vulnerability found
To understand the newly discovered RPC vulnerability, let’s look again at the vulnerability that was patched in April. As we concluded in our previous blog post, an integer overflow bug existed in the RPC runtime library code that, when abused, could lead to a heap buffer overflow — a situation where data is copied onto a buffer that is too small to populate it. This, in turn, allows data to be written out of the buffer’s bounds, on the heap. When exploited properly, this could lead to remote code execution.
To fix this vulnerability, a new call was added to ProcessReceivedPdu:
This call triggers a function that checks exactly whether the integer parameter overflowed:
When looking at OSF_SCALL::GetCoalescedBuffer (the function in which the heap overflow happens), we could also notice the added check:
GetCoalescedBuffer is responsible for coalescing fragments of buffers that have been queued up in ProcessReceivedPdu. The original integer overflow happens when the total length of fragments that have been queued is added to the current received buffer length; this addition leads to an overflow. By invoking a function that checks for overflow, Microsoft fixed the original vulnerability.
However, the patch only partially addressed the vulnerability. During our research, we found that right before allocating memory for the new coalesced buffer, the code adds another 24 bytes to the allocation size (seen above with the call to OSF_SCALL::TransGetBuffer). These 24 bytes are the size of a struct called rpcconn_request_hdr_t, which serves as the buffer header. Since the patch performs the check for integer overflow before adding the header size, it does not take into account this header, which can lead to the same integer overflow that the patch was attempting to mitigate.
The new vulnerability (one in a client-side function and one in a server-side one) has now been mitigated. The new patch adds another call to validate that the addition of 24 bytes does not overflow.
Mitigation
Apply May’s security updates that mitigate this vulnerability.
Block traffic to TCP port 445 from devices outside of the enterprise perimeter.
Limit lateral movement by allowing incoming TCP port 445 only on machines where it is needed (domain controllers, print servers, file servers, etc.).
Disclosure Timeline
April 13, 2022: A report has been sent to Microsoft
April 13, 2022: Status changed from New to Review / Repro
April 22, 2022: Status changed from Review / Repro to Develop
May 10, 2022: Patch has been released
Conclusion
Patching is considered one of the most foundational security measures; a vulnerability is found, a patch is released, the vulnerability is mitigated. While the zero-days get a lot of attention in the media and community in general, as practitioners we know the largest vulnerabilities come from situations similar to this one. This is a great example as to why this process should be continuous and repetitive.
We, as a community, often focus on the original code when searching for bugs, but working specifically on updates and patches offers another aspect of bug hunting, which may facilitate collaboration on finding solutions and allowing for better security all around.
This situation also heavily reiterates the importance of independent security researchers. We would like to encourage other security researchers to continue to analyze this and other patches elsewhere for vulnerabilities.
Have questions or want to discuss what we’ve found? Reach out to us on Twitter @Akamai_Research to let us know what you think.
