openssh unix dev - May 2009 - Memory leak caused by forwarded GSSAPI credential store

Hi guys

While debugging a GSSAPI memory allocation problem not related to OpenSSH, I
found a memory leak in OpenSSH when storing  forwarded GSSAPI credentials
resulting in a growing process segment for each connection that uses GSSAPI
credentials  forwarding. What happens is the following:
In the privileged parent, we are calling ssh_gssapi_storecreds() which itself
calls ssh_gssapi_krb5_storecreds().  ssh_gssapi_krb5_storecreds() makes some
memory allocations in order to save the credentials store for the gssapi client.

  +167          client->store.filename =
xstrdup(krb5_cc_get_name(krb_context, ccache));
  +168          client->store.envvar = "KRB5CCNAME";
  +169          len = strlen(client->store.filename) + 6;
  +170          client->store.envval = xmalloc(len);
  +171          snprintf(client->store.envval, len, "FILE:%s",
client->store.filename);

Those memory allocations are never freed. Moreover, since those memory
allocations are done in the privileged parent (which  is a finite-state machine
and never returns) before forking the unprivileged child, the memory leak gets
doubled for each  connection that uses GSSAPI credential forwarding.

A solution would be the following:
1) Migrate the ssh_gssapi_storecreds() call to the unprivileged child
2) Create a ssh_gssapi_free_store() call in gss-serv.c which frees the memory
allocations. At first I was thinking of  integrating this in the
ssh_gssapi_cleanup_creds() call but freeing the memory is mandatory while the
cleanup of credentials  is the user's choice.
3) Integrate ssh_gssapi_free_store() call in the do_cleanup() call, which is
located in session.c.

Bugzilla item #1601 was created to address this issue.
I also added a patch which solves this issue.

Met vriendelijke groet
Best regards
Bien ? vous

Miguel SANDERS
ArcelorMittal Gent

UNIX Systems & Storage
IT Supply Western Europe | John Kennedylaan 51
B-9042 Gent

T +32 9 347 3538 | F +32 9 347 4901 | M +32478 805 023
E miguel.sanders at arcelormittal.com
www.arcelormittal.com/gent


**** 
This message and any attachment are confidential, intended solely for the use of
the individual or entity to whom it is addressed and may be protected by
professional secrecy or intellectual property rights.
If you have received it by mistake, or are not the named recipient(s), please
immediately notify the sender and delete the message. You are hereby notified
that any unauthorized use, copying or dissemination of any or all information
contained in this message is prohibited.
Arcelormittal shall not be liable for the message if altered, falsified, or in
case of error in the recipient.
This message does not constitute any right or commitment for ArcelorMittal
except when expressly agreed otherwise in writing in a separate agreement.
****

On 23 May 2009, at 11:46, miguel.sanders at arcelormittal.com wrote:
> 1) Migrate the ssh_gssapi_storecreds() call to the unprivileged child
Unfortunately, you can't do this, as GSSAPI credentials need to be  
stored before the PAM stack is invoked (this also means
that the credentials need to be stored in the process which invokes  
pam_setcred, and not in the unprivileged child).
Also, credentials need to be stored whether the user is running  
privsep or not - this change moves credential storage to a privsep  
only code path.

An alternative fix, that doesn't move the location of the storecreds()  
call, is going to be required. One option would be to dispose of these  
structures in the parent as soon as the child is forked (if we're  
running privsep), so removing the leak in the parent, and tidying up  
the leak in the child in the manner you suggest.

Cheers,

Simon.

On Sat, 23 May 2009, miguel.sanders at arcelormittal.com wrote:
> Those memory allocations are never freed. Moreover, since those memory
> allocations are done in the privileged parent (which is a finite-state
> machine and never returns) before forking the unprivileged child,
> the memory leak gets doubled for each connection that uses GSSAPI
> credential forwarding.
I don't think so - the parent in this case is the per-connection privsep
monitor, so any leaks here will not affect the master listening process.

-d