Today, we released MS09-064 which addresses a vulnerability in the License Logging Service. In this post, we provide some background on the service and the severity of the underlying vulnerability.
Background
License Logging Service (LLS) is a feature that was originally designed to help customers manage licenses for Microsoft server products licensed in the Server Client Access License (CAL) model. See http://support.microsoft.com/kb/824196 for more details. The service has been removed from the Windows Server product line starting with Windows Server 2008. Of the remaining supported platforms this issue only affects the Windows Server 2000 version of LLS.
Why is the bulletin severity “critical”?
The bulletin is marked as “critical” for several reasons:
· The service is enabled by default on Windows Server 2000.
· It is accessible by anonymous network connection.
· The underlying issue can lead to extensive heap memory corruption.
What are the mitigating factors?
There are two circumstances though that may lower its severity significantly.
First, the most common scenario of LLS feature calls for managing CALs within trusted enterprise environment, which in most cases means that the network access to the server hosting LLS will be limited to the local segment of a network, usually separated from the Internet by a firewall, proxy server, or other barrier.
Second, the issue leads to a memory corruption, which based on our analysis is very difficult to turn into remote code execution.
Technical details
The root cause of the problem is a lack of string verification for the presence of NULL-terminating characters. An unverified string lacking NULL-termination can be passed to a function, which performs following steps:
· calculate length of the unverified string,
· allocate buffer for a new string, using the calculated length and the length of some other string,
· concatenate two strings in the new buffer.
Since the length calculation of the unverified string can run beyond the string buffer (because of missing NULL termination), we may end up with four different scenarios depending on the heap memory layout at the time of execution:
1. During the string length calculation, code runs beyond string buffer and hits an unallocated memory page, causing read access violation.
2. During the string length calculation, code finds a NULL terminating character beyond the string buffer, returning an exaggerated length. The terminating character falls at lower address than the memory block allocated for the new string. The “exaggerated” string is concatenated with the other string in the new buffer, causing no memory access exception, because the length of the new buffer was calculated using the “exaggerated” length.
3. In scenario 2, another thread owning the block of memory containing the NULL-terminating character incorrectly used for the length calculation, changes the content of memory right after the length calculation, but before string concatenation. This causes a new buffer overflow during concatenation, leading to semi-controlled heap corruption and/or write access violation.
4. In scenario 2, the memory block allocated for the new string includes the NULL-terminating character. The character then gets overwritten during concatenation process, leading to extensive memory copying and causing write access violation.
Scenario 3 relies on a very narrow race condition and thus any attempt to exploit it is likely to be unreliable. The only scenario leading to a potentially reliable exploit is scenario 4. This leads us to a conclusion that real-life exploitation of this vulnerability will be less likely.
-Greg, MSRC Engineering