A QUIC Shutdown: DoS Vulnerability in Windows Servers Running SMB over QUIC
Executive summary
Akamai researcher Ben Barnea found an important vulnerability in Microsoft Windows Server 2022, which was assigned CVE-2023-24898 with a base score of 7.5.
The vulnerability lies in a missing check in a buffer allocation in the srvnet.sys driver.
The vulnerability may lead to remote denial-of-service (DoS) attacks against Windows Server 2022 machines. The vulnerability can be triggered by an unauthenticated attacker over the internet.
Only servers that use SMB over QUIC, a relatively new feature, are vulnerable. To enable this feature, the server must be a Windows Server 2022 Azure Edition.
The vulnerabilities were responsibly disclosed to Microsoft and addressed in May’s Patch Tuesday 2023.
We provide an Insight query for Akamai Guardicore Segmentation users to detect potentially vulnerable servers in their networks.
Introduction
QUIC is a relatively new transport layer protocol that was originally designed by Google but has several implementations. QUIC’s purpose is to provide a more reliable and secure connection while also overcoming common internet problems, such as latency and packet loss. It’s carried over UDP.
Microsoft’s implementation of QUIC is called MsQuic. Windows also incorporates QUIC, using it as a transport layer for the SMB protocol (a feature called SMB over QUIC) and with HTTP/3 in IIS. SMB over QUIC is only available in the Windows Server 2022 Azure edition, while HTTP/3 is available for all IIS deployments running on Windows Server 2022.
The vulnerability discussed in this blog post is located in the driver that implements SMB's transport layer, srvnet.sys.
The vulnerability
To keep a connection’s state, QUIC uses a connection identifier, which uniquely identifies a connection between the client and the server. A client may create multiple concurrent connections. A QUIC connection is also multiplexed; that is, a client and a server can exchange data via multiple streams simultaneously over the same connection.
The code for SMB over QUIC is implemented in srvnet.sys. When the server receives new data on a stream, the function SrvNetQuicServerReceiveEvent is called. The function's purpose is to read a full SMB message sent by the client. After doing so successfully, it transfers the message to the list of SMB messages for further processing.
To read an SMB message, the code first tries to read the SMB message size, which is represented by a four-bytes integer. If it does so successfully, it checks that the size is not larger than the maximum allowed size for an allocation. If the check passes, the code allocates a buffer with this size and tries to read the remaining bytes from the packet into the newly allocated buffer. If it finished reading the whole SMB message, it indicates to the SMB layer that a new SMB message has been received.
The structure of an SMB message is illustrated in Figure 1.
Fig. 1: An SMB message structure in srvnet.sys
The vulnerability happens if fewer than four bytes are received for the SMB message size (Figure 2). In this case, the code will save the X bytes received and will also set PendingMessageSize to 4 minus X — X being the number of bytes received for the message size. The next time a packet is received, it will read the remaining 4 - X bytes needed for the SMB message size.
Fig. 2: A malicious packet would have fewer than four bytes for message size
Once the code finishes reading the message size, it immediately allocates an SMB message without performing verification of this size against the maximum allowed size. Therefore, by sending the size of the SMB message in two packets instead of one, an attacker can bypass the maximum allowed size verification and request an exceptionally large allocation.
Exploitation
To turn this bug into a DoS vulnerability, we need to continuously send packets that trigger the issue described.
But even with the ability to bypass the maximum allowed size, there are still two restrictions:
1. SrvNetAllocateBuffer has a hard limit of 16 MB for allocations.
2. The number of allowed concurrent unauthenticated connections is limited according to the available RAM on the server. This restriction limits exploitation to servers with up to 32 GB RAM. (In the next section, we’ll theorize about how this limitation can be bypassed.)
To exploit this vulnerability, we first tried creating multiple connections and sending two packets each time to cause the server to allocate 16 MB. Repeatedly doing so leads to memory exhaustion. As this vulnerability is in a driver and running in kernel mode, the whole system becomes unstable and unresponsive.
An optimized exploit?
This exploitation requires sending many packets. We believe that by abusing QUIC’s features it’s possible to reduce the number of packets needed.
While QUIC allows for multiple streams over a single connection, it also enables limiting this number through the initial_max_streams_bidi property. SMB over QUIC limits the number of concurrent streams for a connection to one.
Although we can’t improve the exploit by using multiple concurrent streams, we can try to exploit the vulnerability in a different way. Instead of creating multiple concurrent streams, we create one QUIC packet with multiple frames, so that the following sequence occurs serially and repeatedly:
1. Create a stream
2. Trigger the 16 MB allocation by sending two DATA frames
3. Close the stream
This way we can also bypass the unauthenticated connection limit. We’ll leave this as a challenge to the reader.
Detection and mitigation
To find a running SMB over QUIC server, Akamai Guardicore Segmentation users can run the following simple Insight query:
select * from registry where
path="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\EnableSMBQUIC" and data=1
We recommend patching your Windows Server machine, as there are no other available mitigations or workarounds for this vulnerability, except turning off the SMB over QUIC feature.
Summary
QUIC is a relatively new network protocol that guarantees better performance and less latency. Evidently, it has already been adopted and incorporated in two very prominent protocols: IIS (for HTTP/3) and SMB.
We believe QUIC to be an interesting new attack surface in Windows, and in general. Other than the issue described here, another vulnerability, CVE-2023-23392, was fixed in HTTP/3.
We encourage other researchers to look into the different components that use MsQuic, and into MsQuic itself.
