MS13-018 addresses a potential denial-of-service condition in the Windows TCP/IP stack. This vulnerability could be leveraged by an attacker in certain circumstances to exhaust a server’s non paged pool, preventing it from making new TCP connections. The vulnerability is as follows:
- A Windows victim machine has a TCP/IP connection in an ESTABLISHED state to a remote attacker machine, and the Windows victim machine (not the attacker machine) sends a FIN packet to the remote attacker machine to initiate the connection teardown sequence, as outlined in RFC 793.
- The remote machine receives the FIN packet, and replies with an ACK packet, but sets the window size=0. The connection on the Windows victim machine stays “stuck” in the TCP FIN_WAIT_2 state.
In this scenario, the Windows machine doesn’t release the non-paged pool data structures associated with this TCP connection. If steps 1 and 2 above occur repeatedly, it could potentially exhaust the Windows machine’s non-paged pool, leading to the inability to open new TCP connections. The below diagram shows the FIN_WAIT_2 state in which this connection gets stuck:
To trigger this resource exhaustion vulnerability, the attacker would need to find a way to repeatedly establish TCP connections with the Windows victim machine and have the victim machine each time initiate the connection teardown sequence by sending a TCP FIN packet to the attacker machine.
An internet-based attacker would, of course, be blocked by any existing firewalls. The internet-based attacker may also have a difficult time finding a way to cause a targeted application on a Windows-based victim machine to initiate the connection teardown sequence (by sending the FIN packet to the attacker machine). Further, we have determined that HTTP.sys, the stack upon which IIS resides, is not vulnerable to this issue. This issue is more likely to be exposed to attackers within the perimeter firewall.
Below is a graph of the kernel’s non-paged pool usage when a custom script that executes the above steps repeatedly is run overnight:
As shown above, the simulated attack consumes the victim’s non-paged pool up until the point that memory management mechanisms limit the usage and memory consumption plateaus. At this point, the resource exhaustion prevents any new TCP connections from being created, disrupting the server’s intended purpose.
Thanks to Swamy Shivaganga Nagaraju for his investigative work on this case.
- Neil Sikka, MSRC Engineering