Access Violation calling AcceptSecurityContext

From: sherry (yangcooper_at_hotmail.com)
Date: 03/22/05


Date: Tue, 22 Mar 2005 14:05:05 -0800

I built a TLS client and server system using SSPI.

The crash occurred two times at the same place (seems to me as I do not have
Secur32.dll source code)

Here is the call stack:

> Secur32.dll!SecpValidateHandle() + 0x55
         Secur32.dll!_AcceptSecurityContext@36() + 0xd8
        SHOUTIP.exe!TLSTransport::HandleHelloFromClient(_SecHandle *
phContext=0x2f8ddd98, _SecHandle * phCred=0x2f8ddd90, bool fClientAuth=false,
bool fDoInitialRead=true, bool fMTLS=false, unsigned long dwSSPIOutFlags=1)
Line 2141 + 0x4f C++

HandleHelloFromClient is my function, in there I invoke AcceptSecurityContext:

    scRet = AcceptSecurityContext(
                    phCred,
                    phContext,
                    &InBuffer,
                    dwSSPIFlags,
                    SECURITY_NATIVE_DREP,
                    (fInitContext?phContext:NULL),
                    &OutBuffer,
                    &dwSSPIOutFlags,
                    &tsExpiry);

I'm actually is expecting the client finish at this time. But inBuffer
seemed contains "client hello" (70 bytes normally is client hello, 182 bytes
is client finish). At this point AcceptSecurityContext crashed.

I know this call phContext is not NULL, but because the InBuffer might
include wrong data. Isn't crash on wrong data a bit severe?

Another question is why after thousand correct calls, now TLS client is
sending wrong data at client finish?

The memory dump of the 70 bytes in InBuffer is:

0x2777EC30 16 03 01 00 41 01 00 00 3d 03 01 42 3f a0 01 7f 70 e1 04 68 a4
ae 8f 4f 6c b1 d2 d9 04 17 cf d1 bf 9a 38 ....A...=..B? .pá.h¤®Ol±ÒÙ..ÏÑ¿š8
0x2777EC53 29 8f 17 e5 8f f1 44 b2 00 00 16 00 04 00 05 00 0a 00 09 00 64
00 62 00 03 00 06 00 13 00 12 00 63 01 00 ).åñD²............d.b.........c..
0x2777EC76

If some one decode this and let me know this is indeed client hello?

I'm running SIP calls using TLS and call rate is about 10 calls per second.
The crash happened after 10 minutes in the testing. By then hundreds calls
already passed through without problem.

Is there a known memory issue or other issue related to this crash?

Your help is greatly appreciated.

Sherry



Relevant Pages

  • Re: why is rfactor
    ... > 1) If the client predicts somebody to move up into them, ... > a crash, that client will have a 'predict' crash, but when the server ... > actually a crash, you just thought there was, and that client will warp ... > up and put somebody in the wall, ...
    (rec.autos.simulators)
  • -pureg doesnt stick
    ... I have a recent build and running it as a wireless AP (with hostapd WPA-PSK TKIP) using an atheros card. ... I've been trying to get an 802.11b client on and I noticed the -pureg option doesn't seem to stick at bootup. ... the backtrace indicated that the crash occurred in the atheros driver itself ... ...
    (freebsd-current)
  • Re: -pureg doesnt stick
    ... hostapd WPA-PSK TKIP) using an atheros card. ... to login and manually set ath0 to -pureg in order for the 802.11b client ... Thinkpad T41 with an Intel Pro Wireless 2100 card will crash both ...
    (freebsd-current)
  • [Full-disclosure] Multiple vulnerabilities in Sauerbraten engine 2006_02_28
    ... C] clients crash through invalid map ... versus both server and clients ... In short is possible to force the server or the client to read over the ...
    (Full-Disclosure)
  • Multiple vulnerabilities in Sauerbraten engine 2006_02_28
    ... C] clients crash through invalid map ... versus both server and clients ... In short is possible to force the server or the client to read over the ...
    (Bugtraq)