Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

AcceptSecurityContext memory leaks with schannel SSPI

27 views
Skip to first unread message

meros

unread,
Nov 3, 2009, 2:56:22 AM11/3/09
to
I have a server application where every server side socket that uses
SSL was leaking a couple of bytes. I used UMDH.exe to track down the
memory leaks and it turns out they originate from the
AcceptSecurityContext call:

-----
status = AcceptSecurityContext(
myPCredHandle,
myHasCreatedSslContext ? &mySslContext : NULL,
&inBufferDesc,
sspiFlags,
SECURITY_NATIVE_DREP,
myHasCreatedSslContext ? NULL : &mySslContext,
&outBufferDesc,
&contextAttributes,
&expire);
----

The only mention of leaks from this function I can find is the output
buffer it can allocate and the security context. The memory buffers is
ruled out, we don't set that flag and it doesn't not look like it
allocates buffer anyway. The security context if deleted with:

---
status = DeleteSecurityContext(&mySslContext);
---

When the socket is closed.

The leaks that still remain are these (one leak per new socket):

ntdll! ?? ::FNODOBFM::`string'+00012850
kernel32!LocalAlloc+00000062
schannel!SPContextDeserialize+00000706
schannel!SslAddUserContext+000001B0
schannel!SpInitUserModeContext+00000092
Secur32!LsaAcceptSecurityContext+000002EC
Secur32!AcceptSecurityContext+00000129
serverboxtest!mg::serverbox::SslFilter::PrivServerHandshake+00000244
(c:\p4ws\massgate-main\massgate\dev\main\code\services\serverbox\mg
\serverbox\sslfilter.cpp, 338)
serverboxtest!mg::serverbox::SslFilter::FilterIncomingData+000000F6
(c:\p4ws\massgate-main\massgate\dev\main\code\services\serverbox\mg
\serverbox\sslfilter.cpp, 73)
serverboxtest!main+0000014A (c:\p4ws\massgate-main\massgate\dev\main
\code\services\serverboxtest\mg\serverboxtest\serverboxtest.cpp, 155)
serverboxtest!__tmainCRTStartup+0000021C (f:\dd\vctools\crt_bld
\self_64_amd64\crt\src\crt0.c, 327)
serverboxtest!mainCRTStartup+0000000E (f:\dd\vctools\crt_bld
\self_64_amd64\crt\src\crt0.c, 196)
kernel32!BaseThreadInitThunk+0000000D
ntdll!RtlUserThreadStart+0000001D


And:

ntdll! ?? ::FNODOBFM::`string'+00012850
kernel32!LocalAlloc+00000062
schannel!SPContextDeserialize+000006B5
schannel!SslAddUserContext+000001B0
schannel!SpInitUserModeContext+00000092
Secur32!LsaAcceptSecurityContext+000002EC
Secur32!AcceptSecurityContext+00000129
serverboxtest!mg::serverbox::SslFilter::PrivServerHandshake+00000244
(c:\p4ws\massgate-main\massgate\dev\main\code\services\serverbox\mg
\serverbox\sslfilter.cpp, 338)
serverboxtest!mg::serverbox::SslFilter::FilterIncomingData+000000F6
(c:\p4ws\massgate-main\massgate\dev\main\code\services\serverbox\mg
\serverbox\sslfilter.cpp, 73)
serverboxtest!main+0000014A (c:\p4ws\massgate-main\massgate\dev\main
\code\services\serverboxtest\mg\serverboxtest\serverboxtest.cpp, 155)
serverboxtest!__tmainCRTStartup+0000021C (f:\dd\vctools\crt_bld
\self_64_amd64\crt\src\crt0.c, 327)
serverboxtest!mainCRTStartup+0000000E (f:\dd\vctools\crt_bld
\self_64_amd64\crt\src\crt0.c, 196)
kernel32!BaseThreadInitThunk+0000000D
ntdll!RtlUserThreadStart+0000001D

When debugging this it turns out the same leak exists on the client
side as well:

ntdll! ?? ::FNODOBFM::`string'+00012850
kernel32!LocalAlloc+00000062
schannel!SPContextDeserialize+000006B5
schannel!SslAddUserContext+000001B0
schannel!SpInitUserModeContext+00000092
Secur32!LsaInitializeSecurityContextCommon+00000328
Secur32!LsaInitializeSecurityContextA+0000006E
Secur32!InitializeSecurityContextCommon+00000165
Secur32!InitializeSecurityContextA+0000006E
serverboxtest!mg::serverbox::SslFilter::PrivClientHandshake+000001EA
(c:\p4ws\massgate-main\massgate\dev\main\code\services\serverbox\mg
\serverbox\sslfilter.cpp, 456)
serverboxtest!mg::serverbox::SslFilter::FilterIncomingData+000000DB
(c:\p4ws\massgate-main\massgate\dev\main\code\services\serverbox\mg
\serverbox\sslfilter.cpp, 69)
serverboxtest!main+000001AB (c:\p4ws\massgate-main\massgate\dev\main
\code\services\serverboxtest\mg\serverboxtest\serverboxtest.cpp, 156)
serverboxtest!__tmainCRTStartup+0000021C (f:\dd\vctools\crt_bld
\self_64_amd64\crt\src\crt0.c, 327)
serverboxtest!mainCRTStartup+0000000E (f:\dd\vctools\crt_bld
\self_64_amd64\crt\src\crt0.c, 196)
kernel32!BaseThreadInitThunk+0000000D
ntdll!RtlUserThreadStart+0000001D


Has anyone seen this before? Am i missing something? It looks like
it's memory associated with the security context, but I know of no
other way of deleting that memory than what we use now
(DeleteSecurityContext).

Thanks,

/Alexander Schrab

0 new messages