We have received a few inquiries about the full disclosure posting http://seclists.org/fulldisclosure/2007/Dec/0470.html , where a range check was added in Windows XP SP3 for the Terminal Server RPC function RpcWinStationEnumerateProcesses. The speculation stated that this change was to hide an overflow condition, potentially leading to an exploitable vulnerability in previous Windows versions. In reality, this update to the Terminal Service RPC interface definition was made to better adhere to our own RPC best practices.
From IDL Techniques for Better Interface and Method Design:
- For parameters marked with the [out, size_is] attribute tuple, and where the data length is known on the client side or where the client has a reasonable upper bound, the method definition should be similar to the following in terms of parameter attribution and sequence:
outKnownSize
(
[in,range(MIN_COUNT, MAX_COUNT)] long lSize,
[out,size_is(lSize)] UserDataType * pArr
);
In this case, the client provides a fixed size buffer for pArr, allowing the server-side RPC service to allocate a reasonably-sized buffer with a good degree of assurance. Note that in the example the data is received from the server ([out]). The definition is similar for data passed to the server ([in]).
Looking at the IDA disassembly, one can see that this value is used to retrieve a memory block from RtlAllocateHeap. This memory is then passed into NtQuerySystemInformation which populates it with, you guessed it, various system information. If an overflow existed due to this value, it would exist and be fixed in these lower level functions, not in a high level interface definition.
- Security Vulnerability Research & Defense bloggers