Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
This month we released MS11-083 to address an externally found reference counter issue in TCP/IP stack. Here we would like to give further information about the exploitability of this vulnerability. VulnerabilityThe vulnerability presents itself in the specific scenario where an attacker can send a large number of specially crafted UDP packets to a random port that does not have a service listening. While processing these network packets it is observed that some used structures are referenced but not dereferenced properly. This unbalanced reference counting could eventually lead to an integer overflow of the reference counter. Effects of reference count wrap aroundWith the above described vulnerability, when the system is deluged with network packets, the reference counter in the structure will keep incrementing and eventually wrap around.
If a dereference happens just after the counter has wrapped to zero, the structure will be freed. Depending on the timing conditions, four scenarios are possible:• The memory is still mapped and contains the old data. No crash results and the system works as normal.• The memory is unmapped and the system crashes when it is referenced. This results in a system denial-of-service.• The memory is re-allocated for the same structure. No crash results and the system works as normal.• The memory is re-allocated for a different structure. This could result in a system crash, or if attacker-controlled data is present, could lead to memory corruption or remote code execution. Exploitability While the last scenario can theoretically lead to RCE, we believe it is difficult to achieve RCE using this vulnerability considering that the type of network packets required are normally filtered at the perimeter and the small timing window between the release and next access of the structure, and a large number of packets are required to pull off the attack. As a result, we assign an Exploitability Index of "2" for this vulnerability.
Ali Rahbar, Mark Wodrich from MSRC Engineering, Gangadhara Swamy from IDC.
Special thanks to Jeremy Tinder from MSRC.