Memory leaks in Kerberos 5 1.6.4-beta1 and 1.7

[Dan Searle]

Hi,

I came across two memory leaks in the Kerberos 5 libs after using the 
squid_kerb_auth helper in squid which performs single sign with 
KRB5RCACHETYPE=none. I.e. with the replay protection cache switched off.

The reason I switched off the cache was because of performance problems 
with it switched on, after a few thousand authentications in a short 
time period, the cache became a bottleneck with individual 
authentications taking in the order of a few seconds rather than tenths 
or hundredths of a second. This bottleneck seems to be because the 
Kerberos libs perform a linear search of old tickets in the cache to 
prevent replay attacks, and with a large rate of authentication sessions 
the linear search is too inefficient.

Running the squid_kerb_auth helper through valgrind with 
--leak-check=full --leak-resolution=high options, and with the 
environment variable KRB5RCACHETYPE=none here are the results:


after 1 successful authentication, then quit:
==10794== 68 bytes in 1 blocks are definitely lost in loss record 66 of 79
==10794==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==10794==    by 0x40C19D0: krb5_rc_resolve_full (rc_base.c:152)
==10794==    by 0x40BEDF8: krb5_get_server_rcache (srv_rcache.c:107)
==10794==    by 0x403FE9A: krb5_gss_acquire_cred (acquire_cred.c:192)
==10794==    by 0x404B29D: k5glue_acquire_cred (krb5_gss_glue.c:460)
==10794==    by 0x40348C5: gss_add_cred (g_acquire_cred.c:382)
==10794==    by 0x4034D15: gss_acquire_cred (g_acquire_cred.c:188)
==10794==    by 0x8049C31: main (squid_kerb_auth.c:489)


after 2 successful authentications, then quit:
==10710== 68 bytes in 1 blocks are definitely lost in loss record 66 of 80
==10710==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==10710==    by 0x40C19D0: krb5_rc_resolve_full (rc_base.c:152)
==10710==    by 0x40BEDF8: krb5_get_server_rcache (srv_rcache.c:107)
==10710==    by 0x40B8EDD: krb5_rd_req (rd_req.c:89)
==10710==    by 0x403D910: krb5_gss_accept_sec_context 
(accept_sec_context.c:408)
==10710==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
==10710==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==10710==    by 0x40510A7: spnego_gss_accept_sec_context 
(spnego_mech.c:1113)
==10710==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==10710==    by 0x8049CC8: main (squid_kerb_auth.c:495)
==10710==
==10710==
==10710== 136 bytes in 2 blocks are definitely lost in loss record 70 of 80
==10710==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==10710==    by 0x40C19D0: krb5_rc_resolve_full (rc_base.c:152)
==10710==    by 0x40BEDF8: krb5_get_server_rcache (srv_rcache.c:107)
==10710==    by 0x403FE9A: krb5_gss_acquire_cred (acquire_cred.c:192)
==10710==    by 0x404B29D: k5glue_acquire_cred (krb5_gss_glue.c:460)
==10710==    by 0x40348C5: gss_add_cred (g_acquire_cred.c:382)
==10710==    by 0x4034D15: gss_acquire_cred (g_acquire_cred.c:188)
==10710==    by 0x8049C31: main (squid_kerb_auth.c:489)


after 5 successful authentications, then quit:
==10849== 272 bytes in 4 blocks are definitely lost in loss record 73 of 80
==10849==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==10849==    by 0x40C19D0: krb5_rc_resolve_full (rc_base.c:152)
==10849==    by 0x40BEDF8: krb5_get_server_rcache (srv_rcache.c:107)
==10849==    by 0x40B8EDD: krb5_rd_req (rd_req.c:89)
==10849==    by 0x403D910: krb5_gss_accept_sec_context 
(accept_sec_context.c:408)
==10849==    by 0x404B192: k5glue_accept_sec_context (krb5_gss_glue.c:434)
==10849==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==10849==    by 0x40510A7: spnego_gss_accept_sec_context 
(spnego_mech.c:1113)
==10849==    by 0x4034178: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==10849==    by 0x8049CC8: main (squid_kerb_auth.c:495)
==10849==
==10849==
==10849== 340 bytes in 5 blocks are definitely lost in loss record 74 of 80
==10849==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==10849==    by 0x40C19D0: krb5_rc_resolve_full (rc_base.c:152)
==10849==    by 0x40BEDF8: krb5_get_server_rcache (srv_rcache.c:107)
==10849==    by 0x403FE9A: krb5_gss_acquire_cred (acquire_cred.c:192)
==10849==    by 0x404B29D: k5glue_acquire_cred (krb5_gss_glue.c:460)
==10849==    by 0x40348C5: gss_add_cred (g_acquire_cred.c:382)
==10849==    by 0x4034D15: gss_acquire_cred (g_acquire_cred.c:188)
==10849==    by 0x8049C31: main (squid_kerb_auth.c:489)

Please note that these leaks do not occur with the KRB5RCACHETYPE 
environment variable unset, i.e. with the ticket cache enabled.

Regards, Dan...

-- 
Dan Searle

CensorNet Ltd - professional & affordable Web & E-mail filtering
email: dan.searle at censornet.com web: www.censornet.com
tel: 0845 230 9590 / fax: 0845 230 9591 / support: 0845 230 9592
snail: Vallon House, Vantage Court Office Park, Winterbourne,
       Bristol, BS16 1GW, UK.

CensorNet Ltd is a registered company in England & Wales No. 05518629
VAT registration number 901-2048-78
Any views expressed in this email communication are those of the
individual sender, except where the sender specifically states them to
be the views of a member of Censornet Ltd.  Censornet Ltd. does not
represent, warrant or guarantee that the integrity of this
communication has been maintained nor that the communication is free
of errors or interference. 


------------------------------------------------------------------------------------
Scanned for viruses, spam and offensive content by CensorNet MailSafe

Try CensorNet free for 14 days. Provide Internet access on your terms.
Visit www.censornet.com for more information.