Memory leaks in Kerberos 5 1.6.4-beta1 and 1.7

[Dan Searle-2]

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@... web: www.censornet.com
tel: [phone] / fax: [phone] / 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.

_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Ken Raeburn]

On Nov 6, 2009, at 11:22, Dan Searle wrote:
> 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.

These should be fixed in 1.7.1.  You can see the ticket (with a link  
to a patch you can try out) at http://krbdev.mit.edu/rt/Ticket/Display.html?id=6514 
  .  (Both problems listed in your email seem to be regarding the same  
allocation site where we weren't freeing the storage, just with  
different callers further up the stack.)  If that doesn't fix the  
problem for you, please let us know.

Ken


--
Ken Raeburn / raeburn@... / no longer at MIT Kerberos Consortium

_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Dan Searle-2]

Hi,

I tried the patch (applied to the 1.7 public release as I don't have
access to the 1.7.1 branch), however now I get a different leak:

==16212== 50 bytes in 2 blocks are definitely lost in loss record 66 of 81
==16212==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==16212==    by 0x4195FCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==16212==    by 0x41DF9D9: (within /lib/tls/i686/cmov/libc-2.7.so)
==16212==    by 0x41E1AD8: getaddrinfo (in /lib/tls/i686/cmov/libc-2.7.so)
==16212==    by 0x4279F38: krb5int_getaddrinfo (fake-addrinfo.c:315)
==16212==    by 0x40BE474: krb5_sname_to_principal (sn2princ.c:112)
==16212==    by 0x4042318: krb5_gss_import_name (import_name.c:99)
==16212==    by 0x403703B: gssint_import_internal_name (g_glue.c:306)
==16212==    by 0x403502F: gss_add_cred (g_acquire_cred.c:383)
==16212==    by 0x403535B: gss_acquire_cred (g_acquire_cred.c:198)
==16212==    by 0x8049C31: main (squid_kerb_auth.c:489)

Regards, Dan...

Ken Raeburn wrote:

> On Nov 6, 2009, at 11:22, Dan Searle wrote:
>  
>> 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.
>>    
>
> These should be fixed in 1.7.1.  You can see the ticket (with a link  
> to a patch you can try out) at http://krbdev.mit.edu/rt/Ticket/Display.html?id=6514 
>   .  (Both problems listed in your email seem to be regarding the same  
> allocation site where we weren't freeing the storage, just with  
> different callers further up the stack.)  If that doesn't fix the  
> problem for you, please let us know.
>
> Ken
>
>
>  
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.698 / Virus Database: 270.14.52/2484 - Release Date: 11/06/09 07:38:00
>
>  

--
Dan Searle

CensorNet Ltd - professional & affordable Web & E-mail filtering
email: dan.searle@... web: www.censornet.com
tel: [phone] / fax: [phone] / 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.

_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Ken Raeburn]

On Nov 6, 2009, at 13:02, Dan Searle wrote:
> Hi,
>
> I tried the patch (applied to the 1.7 public release as I don't have  
> access to the 1.7.1 branch),

If you don't have access to the anonymous subversion server, there's a  
nightly snapshot made available for ftp (but updated only when there  
are actually changes); info is at http://web.mit.edu/kerberos/krb5-current.html 
  .  The "krb5-1.7-current" snapshot is from the 1.7.x branch, last  
updated 9/29 when several bugfixes were incorporated.

> however now I get a different leak:
>
> ==16212== 50 bytes in 2 blocks are definitely lost in loss record 66  
> of 81
> ==16212==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
> ==16212==    by 0x4195FCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
> ==16212==    by 0x41DF9D9: (within /lib/tls/i686/cmov/libc-2.7.so)
> ==16212==    by 0x41E1AD8: getaddrinfo (in /lib/tls/i686/cmov/
> libc-2.7.so)
> ==16212==    by 0x4279F38: krb5int_getaddrinfo (fake-addrinfo.c:315)
> ==16212==    by 0x40BE474: krb5_sname_to_principal (sn2princ.c:112)
> ==16212==    by 0x4042318: krb5_gss_import_name (import_name.c:99)
> ==16212==    by 0x403703B: gssint_import_internal_name (g_glue.c:306)
> ==16212==    by 0x403502F: gss_add_cred (g_acquire_cred.c:383)
> ==16212==    by 0x403535B: gss_acquire_cred (g_acquire_cred.c:198)
> ==16212==    by 0x8049C31: main (squid_kerb_auth.c:489)
>
> Regards, Dan...

That's storage allocated by the C library's getaddrinfo routine.  As  
near as I can tell, the fake-addrinfo.c code doesn't mess with the  
returned structures before freeing them; we just copy the data out  
into storage we're managing.  So it might be a libc bug.  You could  
try a little test:

In tests/resolve in your build tree, "make addrinfo-test fake-addrinfo-
test".  That builds two programs by the obvious names; one will test  
the libc getaddrinfo routine, and the other tests our wrapper around  
it.  Try running both under valgrind, giving the local host name as an  
argument.  If valgrind reports a leak in addrinfo-test, it's very  
likely to be a libc bug; if it only reports a problem in fake-addrinfo-
test, then it's MIT's bug.

Ken


--
Ken Raeburn / raeburn@... / no longer at MIT Kerberos Consortium

_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Dan Searle-2]

Hi,

I downloaded the krb5-1.7-current snapshot, extracted, cd
krb5-1.7-current/src, ./configure, cd tests/resolve, make, then ran both
addrinfo-test and fake-addrinfo-test through valgrind with
--leack-check=full and --leak-resolution=high.

addrinfo-test:
No leaks.

fake-addrinfo-test:
==23357== 25 bytes in 1 blocks are definitely lost in loss record 1 of 1
==23357==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==23357==    by 0x40B9FCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
==23357==    by 0x41039D9: (within /lib/tls/i686/cmov/libc-2.7.so)
==23357==    by 0x4105AD8: getaddrinfo (in /lib/tls/i686/cmov/libc-2.7.so)
==23357==    by 0x4030F38: krb5int_getaddrinfo (fake-addrinfo.c:315)
==23357==    by 0x8048AB5: main (addrinfo-test.c:263)
==23357==
==23357== LEAK SUMMARY:
==23357==    definitely lost: 25 bytes in 1 blocks.
==23357==      possibly lost: 0 bytes in 0 blocks.
==23357==    still reachable: 0 bytes in 0 blocks.
==23357==         suppressed: 0 bytes in 0 blocks.

The version of libc6 is the latest available package in Ubuntu Hardy,
i.e. 2.7-10ubuntu5. Is this a libc bug or an MIT bug?

Regards, Dan...

Ken Raeburn wrote:

> On Nov 6, 2009, at 13:02, Dan Searle wrote:
>  
>> Hi,
>>
>> I tried the patch (applied to the 1.7 public release as I don't have  
>> access to the 1.7.1 branch),
>>    
>
> If you don't have access to the anonymous subversion server, there's a  
> nightly snapshot made available for ftp (but updated only when there  
> are actually changes); info is at http://web.mit.edu/kerberos/krb5-current.html 
>   .  The "krb5-1.7-current" snapshot is from the 1.7.x branch, last  
> updated 9/29 when several bugfixes were incorporated.
>
>
>  
>> however now I get a different leak:
>>
>> ==16212== 50 bytes in 2 blocks are definitely lost in loss record 66  
>> of 81
>> ==16212==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
>> ==16212==    by 0x4195FCF: strdup (in /lib/tls/i686/cmov/libc-2.7.so)
>> ==16212==    by 0x41DF9D9: (within /lib/tls/i686/cmov/libc-2.7.so)
>> ==16212==    by 0x41E1AD8: getaddrinfo (in /lib/tls/i686/cmov/
>> libc-2.7.so)
>> ==16212==    by 0x4279F38: krb5int_getaddrinfo (fake-addrinfo.c:315)
>> ==16212==    by 0x40BE474: krb5_sname_to_principal (sn2princ.c:112)
>> ==16212==    by 0x4042318: krb5_gss_import_name (import_name.c:99)
>> ==16212==    by 0x403703B: gssint_import_internal_name (g_glue.c:306)
>> ==16212==    by 0x403502F: gss_add_cred (g_acquire_cred.c:383)
>> ==16212==    by 0x403535B: gss_acquire_cred (g_acquire_cred.c:198)
>> ==16212==    by 0x8049C31: main (squid_kerb_auth.c:489)
>>
>> Regards, Dan...
>>    
>
> That's storage allocated by the C library's getaddrinfo routine.  As  
> near as I can tell, the fake-addrinfo.c code doesn't mess with the  
> returned structures before freeing them; we just copy the data out  
> into storage we're managing.  So it might be a libc bug.  You could  
> try a little test:
>
> In tests/resolve in your build tree, "make addrinfo-test fake-addrinfo-
> test".  That builds two programs by the obvious names; one will test  
> the libc getaddrinfo routine, and the other tests our wrapper around  
> it.  Try running both under valgrind, giving the local host name as an  
> argument.  If valgrind reports a leak in addrinfo-test, it's very  
> likely to be a libc bug; if it only reports a problem in fake-addrinfo-
> test, then it's MIT's bug.
>
> Ken
>
>
>  
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.698 / Virus Database: 270.14.52/2484 - Release Date: 11/06/09 07:38:00
>
>  

--
Dan Searle

CensorNet Ltd - professional & affordable Web & E-mail filtering
email: dan.searle@... web: www.censornet.com
tel: [phone] / fax: [phone] / 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.

_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Ken Raeburn]

On Nov 9, 2009, at 05:09, Dan Searle wrote:
> The version of libc6 is the latest available package in Ubuntu  
> Hardy, i.e. 2.7-10ubuntu5. Is this a libc bug or an MIT bug?

There's a workaround in the 1.7 release code for an old getaddrinfo  
bug in glibc; the workaround introduces a memory leak.  Greg put a fix  
in back in August to disable the workaround if the glibc version is  
2.4 or later, since the bug was fixed in 2.3.4.  See http://krbdev.mit.edu/rt/Ticket/Display.html?id=6534 
  and some of the comments in src/util/support/fake-addrinfo.c for  
details.  I don't think it's been added to the 1.7 branch yet, so it  
wouldn't have been in the snapshot you got.

You can get a link to the patch from the RT page, or you can try a  
snapshot from the main development trunk ("krb5-current"), if you like.

Ken
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev