There's a function in the Windows kernel responsible for getting messages from a sending thread forwarded over to the receiving thread for interthread communication; xxxInterSendMsgEx. Certain message types need a buffer returned, and hence, allocated space needs to be defined; a call to the Win32AllocPoolWithQuota function is made after determining the needed buffer size. How this is determined is important. There are two considerations: the message type and the arguments that were passed to the system call requiring the message to be sent. If the expected returned data is a string, then we have the question of how the characters are encoded; good ol'-fashioned ASCII or WCHAR. Whereas ASCII is a specific character encoding with a standardized size of 8 bits per character, WCHAR means wide character and more broadly refers to character sets that use more space than 8 bits. Back at the end of the 1980s, the Universal Coded Character Set (UCS) appeared, standardized as ISO/IEC 10646; designed to support multiple languages, it could use 16 or even 32 bits per character. The UCS character repertoire is synchronized with the popular Unicode standard, and today's popular Unicode encoding formats include UTF-8, UTF-16, and UTF-32, with only UTF-8 having the same space requirement per character as ASCII. Thus, allocating space for the ASCII-encoded message Hello, World! will require 13 bytes of memory; but in a 32-bit WCHAR format, I'll need 52 bytes for the same message.
Back to the inter-thread communication in the kernel, the CopyOutputString function goes about its business of filling up the kernel buffer while converting characters as needed using two criteria: the data type of the receiving window and the requested data type of the last argument passed to the message call. This gives us a total of four combinations handled in four different ways:
| Receiving window data type | Message call last argument data type | Action for filling buffer |
| ASCII | ASCII | Copy data with strncpycch |
| WCHAR | WCHAR | Copy data with wcsncpycch |
| ASCII | WCHAR | Convert data to wide with MBToWCSEx |
| WCHAR | ASCII | Convert data from wide with WCSToMBEx |
The key here is that these different actions will result in different data lengths, but the buffer has already been allocated by xxxInterSendMsgEx via Win32AllocPoolWithQuota. I think you see where this is going, so let's fast forward to our Metasploit module, which is ready to create a scenario whereby the pool will overflow, allowing us to execute code with kernel power.