_gsskrb5_store_cred_into2 abuses putenv, likely leading to use-after-free

[riastradh]

Describe the bug
_gsskrb5_store_cred_into2 sometimes allocates an environment variable assignment with malloc:

heimdal/lib/gssapi/krb5/store_cred.c

Line 335 in 1b954fa

major_status = add_env(minor_status, envp, "KRB5CCNAME", fullname);

heimdal/lib/gssapi/krb5/store_cred.c

Line 71 in 1b954fa

major = gss_add_buffer_set_member(minor, &b, env);

heimdal/lib/gssapi/mech/gss_buffer_set.c

Line 85 in 1b954fa

p->value = malloc(member_buffer->length);

Then it passes this assignment to putenv:

heimdal/lib/gssapi/krb5/store_cred.c

Line 345 in 1b954fa

(major_status = set_proc(minor_status, *envp)) != GSS_S_COMPLETE)

heimdal/lib/gssapi/krb5/store_cred.c

Line 87 in 1b954fa

putenv(env->elements[i].value);

Then it frees the assignment:

heimdal/lib/gssapi/krb5/store_cred.c

Line 347 in 1b954fa

(void) gss_release_buffer_set(&junk, &env);

heimdal/lib/gssapi/mech/gss_buffer_set.c

Line 112 in 1b954fa

gss_release_buffer(&minor, &((*buffer_set)->elements[i]));

heimdal/lib/gssapi/mech/gss_release_buffer.c

Line 38 in 1b954fa

free(buffer->value);

At this point, there is still a pointer to the freed environment variable assignment string in environ.

Subsequent calls by the same process to exec or posix_spawn will pass this pointer along. If the memory has been recycled, this may leak secrets into other processes.

To Reproduce
code inspection

Expected behavior
no putenv abuse