Subject: | gss_add_cred() aliases memory when creating extended cred, leading to memory bugs |
gss_add_cred() has an input_cred_handle parameter and and
output_cred_handle parameter, both of which are optional (but the
caller has to specify at least one). Per RFC 2744, it can be used in
three modes:
1. Create a new cred handle with one mech cred (output with no input)
2. Add a mech cred to an existing cred handle (input with no output)
3. "compose a new credential containing all credential-elements of
the original in addition to the newly-acquire credential-element"
(input and output)
The first two cases work (except for a memory leak in case 1 as
reported in ticket 8729), but in the third case we make a shallow
copy of the existing OIDs and mechanism credentials from the input
handle. Once one of the cred handles is released, the other cred
handle contains invalid pointers which are then incorrectly accessed
when the other handle is used or released (use after free and/or
double free).
This bug is quite old, so it seems unlikely that gss_add_cred() is
being used this way in programs, but we should of course fix it. The
fix will be kind of awkward, as GSSAPI provides no way to copy cred
handles. We now have gss_export_cred() and gss_import_cred(); we can
use those to inefficiently copy credentials under the assumption that
this will not be a common operation.
output_cred_handle parameter, both of which are optional (but the
caller has to specify at least one). Per RFC 2744, it can be used in
three modes:
1. Create a new cred handle with one mech cred (output with no input)
2. Add a mech cred to an existing cred handle (input with no output)
3. "compose a new credential containing all credential-elements of
the original in addition to the newly-acquire credential-element"
(input and output)
The first two cases work (except for a memory leak in case 1 as
reported in ticket 8729), but in the third case we make a shallow
copy of the existing OIDs and mechanism credentials from the input
handle. Once one of the cred handles is released, the other cred
handle contains invalid pointers which are then incorrectly accessed
when the other handle is used or released (use after free and/or
double free).
This bug is quite old, so it seems unlikely that gss_add_cred() is
being used this way in programs, but we should of course fix it. The
fix will be kind of awkward, as GSSAPI provides no way to copy cred
handles. We now have gss_export_cred() and gss_import_cred(); we can
use those to inefficiently copy credentials under the assumption that
this will not be a common operation.