VULHUB ™

We have discovered that the msrpc!LRPC_CASSOCIATION::AlpcSendCancelMessage function sends an ALPC message with portions of uninitialized memory from the local stack frame on Windows 7 64-bit (other versions were not tested). The message is 0x18 bytes long, 8 of which are uninitialized. The layout of the memory area is as follows: ``` 00000000: 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 ................ 00000010: 00 00 00 00 ff ff ff ff ?? ?? ?? ?? ?? ?? ?? ?? ................ ``` Where 00 denote bytes which are properly initialized, while ff indicate uninitialized values. This buffer can be then read back into user-mode with e.g. the nt!NtAlpcSendWaitReceivePort syscall, as observed during system runtime on our test machine: ``` kd> k # Child-SP RetAddr Call Site 00 fffff880`0220ea58 fffff800`029a0478 nt!memcpy+0x3 01 fffff880`0220ea60 fffff800`029a253e nt!AlpcpReceiveMessage+0x3c5 02 fffff880`0220eb00 fffff800`0268d093 nt!NtAlpcSendWaitReceivePort+0x1fe 03 fffff880`0220ebb0...

We have discovered that the msrpc!LRPC_CASSOCIATION::AlpcSendCancelMessage function sends an ALPC message with portions of uninitialized memory from the local stack frame on Windows 7 64-bit (other versions were not tested). The message is 0x18 bytes long, 8 of which are uninitialized. The layout of the memory area is as follows: ``` 00000000: 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 ................ 00000010: 00 00 00 00 ff ff ff ff ?? ?? ?? ?? ?? ?? ?? ?? ................ ``` Where 00 denote bytes which are properly initialized, while ff indicate uninitialized values. This buffer can be then read back into user-mode with e.g. the nt!NtAlpcSendWaitReceivePort syscall, as observed during system runtime on our test machine: ``` kd> k # Child-SP RetAddr Call Site 00 fffff880`0220ea58 fffff800`029a0478 nt!memcpy+0x3 01 fffff880`0220ea60 fffff800`029a253e nt!AlpcpReceiveMessage+0x3c5 02 fffff880`0220eb00 fffff800`0268d093 nt!NtAlpcSendWaitReceivePort+0x1fe 03 fffff880`0220ebb0 00000000`772ac58a nt!KiSystemServiceCopyEnd+0x13 04 00000000`028af748 000007fe`ff241f0e ntdll!NtAlpcSendWaitReceivePort+0xa 05 00000000`028af750 000007fe`ff290fb4 RPCRT4!ReceiveMessage+0xba 06 00000000`028af7b0 000007fe`ff26ef85 RPCRT4!LRPC_ADDRESS::ProcessIO+0x151 07 00000000`028af8b0 00000000`772c2920 RPCRT4!LrpcIoComplete+0xa5 08 00000000`028af940 00000000`77279e35 ntdll!TppAlpcpExecuteCallback+0x2cd 09 00000000`028af9b0 00000000`771559cd ntdll!TppWorkerThread+0x554 0a 00000000`028afc40 00000000`7728a561 kernel32!BaseThreadInitThunk+0xd 0b 00000000`028afc70 00000000`00000000 ntdll!RtlUserThreadStart+0x1d kd> db rdx rdx+r8-1 fffff8a0`01195130 04 00 00 00 bb bb bb bb-00 00 00 00 02 00 00 00 ................ fffff8a0`01195140 00 00 00 00 bb bb bb bb ........ ``` It is not clear if any special privileges need to be held to access the data leaked by msrpc.sys. In our case, the process reading from the ALPC port was svchost.exe, but we suspect that more restricted processes could access the affected functionality, too. We are leaving it up to the vendor to determine if the leak can be triggered within the context of a regular system user.