RPC-Laufzeit, die Zweite: Die Entdeckung einer neuen Sicherheitslücke
Zusammenfassung
- Akamai-Forscher Ben Barnea fand eine neue große Sicherheitslücke in der RPC-Laufzeitbibliothek (Remote Procedure Call): 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 all three 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:
Dieser Aufruf löst eine Funktion aus, die genau prüft, ob der Ganzzahlparameter übergelaufen ist:
Wenn wir uns OSF_SCALL::GetCoalescedBuffer (die Funktion, in der der Heap-Überlauf stattfindet) anschauen, sehen wir die neue Prüfung:
GetCoalescedBuffer ist für die Zusammenführung von Puffer-Fragmenten verantwortlich, die in ProcessReceivedPdu in der Warteschlange stehen. Der ursprüngliche Ganzzahlüberlauf tritt auf, wenn die Gesamtlänge der Fragmente, die in der Warteschlange stehen, zur aktuell empfangenen Pufferlänge addiert wird; diese Addition führt zu einem Überlauf. Durch eine Funktion, die auf Überlauf prüft, hat Microsoft die ursprüngliche Sicherheitslücke behoben.
Der Patch behebt die Sicherheitslücke jedoch nur teilweise. Während unserer Recherche haben wir festgestellt, dass der Code vor der Speicherzuordnung für den neuen zusammengeführten Puffer weitere 24 Bytes zur Zuordnungsgröße hinzufügt (siehe oben beim Aufruf von OSF_SCALL::TransGetBuffer). Diese 24 Bytes entsprechen der Größe einer Struktur namens rpcconn_request_hdr_t, die als Pufferheader dient. Da der Patch die Prüfung auf Ganzzahlüberlauf vor dem Hinzufügen der Headergröße durchführt, wird dieser Header nicht berücksichtigt. Das kann zu demselben Ganzzahlüberlauf führen, den der Patch beheben sollte.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.
