I recently discovered all of this due to extensive debugging to discover why several games have stopped working. The question is how do I get Microsoft to release a patch about this and how do I inform them of the bug. If I go to their site their support is all crap and they want you to use up incidents or pay for support which is crap. I submitted it to the wish list thing but I doubt that goes anywhere. I want to talk to someone who actually knows what they are doing on the DirectX development team. Maybe you guys know more about this thanks .

There exists a flaw in the old Directplay(up to 4a) interfaces supported in DirectX 9.0+. In the library file dpwsockx.dll with debugging symbols on the flaw is found in the FastReceive routine. If you try to receive more than 1000h bytes of user data it will not allow it and in fact errors fatally. The following code snippit from dpwsockx.dll from the latest DirectX 9.0b illustrates the problem

.text:5DF03564 and eax, 0FFFFFh ; trim off flags to get number of bytes to receive
.text:5DF03569 mov edi, eax ; put it in the edi as well
.text:5DF0356B jz short loc_5DF03596 ; if 0 bytes then okay
.text:5DF0356D cmp edi, 1000h ; should not be hardcoded at 1000h should be set to buffer size and compared with that
.text:5DF03573 mov [esi+4Ch], edi
.text:5DF03576 jbe short loc_5DF03596 ; if less than or equal to 1000h bytes
.text:5DF03578 cmp dword ptr [esi+54h], 0 ; some sort of flag that cannot be set...
.text:5DF0357C jz short loc_5DF0350D ; if the flag is 0 then fail!
.text:5DF0357E push edi
.text:5DF0357F call _SP_MemAlloc ; do what we should do...

This is from the routine FastReceive in dpwsockx.dll. FastReceive is always used if you have valid Winsock2 DLL library function handles as selected here: FastStreamReceiveThreadProc is what calls FastReceive to do its work.

.text:5DF063C7 push offset _FastStreamReceiveThreadProc@4 ; FastStreamReceiveThreadProc(x)
.text:5DF063CC jmp short loc_5DF063D3
.text:5DF063CE ; ---------------------------------------------------------------------------
.text:5DF063CE
.text:5DF063CE loc_5DF063CE: ; CODE XREF: StartPlayerListenThreads(x,x,x)+58j
.text:5DF063CE push offset _StreamReceiveThreadProc@4 ; lpStartAddress
.text:5DF063D3

Those are the two different options but since the old StreamReceiveThreadProc is never used even though it does not have the 1000h byte limit glitch. This is a confirmed DirectX 9.0+ glitch that affects all interfaces of Directplay from 4a and prior. How can this be reported to Microsoft so a patch can be issued? This has actually taken down a whole game from working.

Snatch

If I understand it correctly, the data in question is received over a network connection? It sounds like a textbook buffer overflow, which could even possibly be used to take over people's computers (I didn't examine the posted code, just read your description briefly, but anyway). If this is the case, you will be sure to get all the attention you want if you publish it. My recommendation would be to post it to e.g. the BugTraq mailing list, as a buffer overflow in a Microsoft network API. This way Microsoft will be guaranteed to notice and act upon it very quickly, and you might even be credited in one of Microsofts high-profile security patches if you're lucky.

I know Microsoft do have some easy accessible email address for reporting such serious security vulnerabilities though, I just don't have it in my head at the moment.

BugTraq might not want to post it if you haven't spoken to Microsoft first, but in that case you should easily be able to find other similar mailing lists with more "full disclosure" like policies. Just hurry before someone takes the glory from you after reading this post.

But remember, if I have misunderstood, and it is after all not a problem related to reading data over the network, it might not be a security vulnerability of nearly the same magnitude, just so you know.

Hmm, after looking at your code it seems I misinterpreted the term "errors fatally". I thought that you meant a program crash, but it seems you only meant that the application/function issues a fatal error code. In this case it can most likely not be exploited by buffer-overrun, and you can forget the publicity and easy attention from MS.

hxxp://www.governmentsecurity.org

-nt20