If the canonicalize flag is set, the MIT KDC always return the client
principal when KRB5_KDC_ERR_C_PRICIPAL_UNKNOWN is returned.

Check that this is really a referral by testing that the returned
client realm differs from the requested one.

Signed-off-by: Simo Sorce <simo@redhat.com>

In profile_iterator(), return PROF_MAGIC_ITERATOR if *iter_p is NULL,
instead of dereferencing a null pointer, as we did prior to 1.10.
Correct calling code will not trigger this case, but incorrect code
has been reported in the field.

ticket: 8059 (new)
target_version: 1.13.1
tags: pullup

Declare User-Password as having type "octets" instead of "string" or
pyrad 2.x will throw a decoding error when retrieving it.

ticket: 8053 (new)
target_version: 1.13.1
tags: pullup

When a FILE ccache method returns an error, append the filename to the
standard message for the code.  Remove code to set extended messages
in helper functions as they would just be overwritten.

Also change the interpretation of errno values.  Treat ENAMETOOLONG as
KRB5_FCC_NOFILE instead of KRB5_FCC_INTERNAL, since it has an external
cause and a name that long can't be opened by normal means.  Treat
EROFS as KRB5_FCC_PERM.  Treat ENOTDIR and ELOOP as KRB5_FCC_NOFILE
instead of KRB5_FCC_PERM as both errors imply that the full pathname
doesn't exist.  Treat EBUSY and ETXTBSY as KRB5_CC_IO instead of
KRB5_FCC_PERM as they indicate a conflict rather than a permission
issue.

[ghudson@mit.edu: renamed set_error to set_errmsg_filename; removed
now-inoperative code to set extended messages in helper functions;
trimmed changes to interpret_errno; clarified and shortened commit
message]

ticket: 8052 (new)

Linux 3.15 has added OFD locks, which contend with POSIX file locks
but are owned by the open file description instead of the process.
Use these in krb5_lock_file where available, for safer concurrency
behavior.

ticket: 8023 (new)

Remove extra 'i' from "create_standalone_prinicipal".  While here,
pick a slightly shorter name for the variable.

This eliminates a potential leak of the bv_val members from
krb5_encode_krbsecretkey().

The secretkey variable is initialized to NULL and compared against
NULL, but never actually set to anything after initialization.

Remove the variable and all code that would have executed if it
was non-NULL.

Confirm that kadmind does not crash when creating/modifying a principal
to have no keys, and confirm that no keys are present after a
purgekeys -all.

Operations like "kadmin -q 'addprinc -nokey foo'" or
"kadmin -q 'purgekeys -all foo'" result in principal entries with
no keys present, so krb5_encode_krbsecretkey() would just return
NULL, which then got unconditionally dereferenced in
krb5_add_ber_mem_ldap_mod().

Apply some fixes to krb5_encode_krbsecretkey() to handle zero-key
principals better, correct the test for an allocation failure, and
slightly restructure the cleanup handler to be shorter and more
appropriate for the usage.  Once it no longer short-circuits when
n_key_data is zero, it will produce an array of length two with both
entries NULL, which is treated as an empty list by the LDAP library,
the correct behavior for a keyless principal.

However, attributes with empty values are only handled by the LDAP
library for Modify operations, not Add operations (which only get
a sequence of Attribute, with no operation field).  Therefore, only
add an empty krbprincipalkey to the modlist when we will be performing a
Modify, and not when we will be performing an Add, which is conditional
on the (misspelled) create_standalone_prinicipal boolean.

CVE-2014-5354:

In MIT krb5, when kadmind is configured to use LDAP for the KDC
database, an authenticated remote attacker can cause a NULL
dereference by inserting into the database a principal entry which
contains no long-term keys.

In order for the LDAP KDC backend to translate a principal entry
from the database abstraction layer into the form expected by the
LDAP schema, the principal's keys are encoded into a
NULL-terminated array of length-value entries to be stored in the
LDAP database.  However, the subroutine which produced this array
did not correctly handle the case where no keys were present,
returning NULL instead of an empty array, and the array was
unconditionally dereferenced while adding to the list of LDAP
operations to perform.

Versions of MIT krb5 prior to 1.12 did not expose a way for
principal entries to have no long-term key material, and
therefore are not vulnerable.

    CVSSv2 Vector: AV:N/AC:M/Au:S/C:N/I:N/A:P/E:H/RL:OF/RC:C

ticket: 8041 (new)
tags: pullup
target_version: 1.13.1
subject: kadmind with ldap backend crashes when putting keyless entries