Bug 2186 - libads/kerberos.c:get_service_ticket() frees uninitialized pointer; random net ads join failure question
Summary: libads/kerberos.c:get_service_ticket() frees uninitialized pointer; random ne...
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: net utility (show other bugs)
Version: 3.0.10
Hardware: Other other
: P3 normal
Target Milestone: none
Assignee: Jim McDonough
QA Contact: Samba QA Contact
Depends on:
Reported: 2004-12-22 14:47 UTC by Buck Huppmann
Modified: 2005-08-24 10:25 UTC (History)
0 users

See Also:

almost too obvious to submit patch (666 bytes, patch)
2004-12-22 14:48 UTC, Buck Huppmann
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Buck Huppmann 2004-12-22 14:47:39 UTC
if the kerberos_kinit_password() fails, the function branches to out:,
skipping the zero-ing of the creds struct, so it contains uninitilized
pointers that are free()-ed. attached patch just moves the zero-initial-
ization up a couple lines

while i have you attention, though, i'm wondering how the new key-salt-
guessing code is supposed to work. in net_ads_join(), the calls to
kerberos_derive_salting_principal() and
kerberos_derive_cifs_salting_principals() don't use the ADS_STRUCT that
the rest of the function's preceding callees do. hence, they may end up
talking to a different ADS server than the one that processed the join,
depending on how the KDC is resolved--especially if one's followed the
advice in the Howto and not set up a [realms] entry in krb5.conf. so,
unless your AD replication is a bit quicker than ours is around here,
kerberos_derive_salting_principal() may eventually result in a
KDC_ERR_C_PRINCIPAL_UNKNOWN being returned by the KDC--which is how i
found the uninitialized-pointer-free bug, probably needless to say,
but it ties this bug-report-cum-AD-info-probe together nicely
Comment 1 Buck Huppmann 2004-12-22 14:48:22 UTC
Created attachment 864 [details]
almost too obvious to submit patch
Comment 3 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:25:14 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.