Fix KDC race in t_unlockiter.py

The second KDC startup in t_unlockiter.py could race with the
garbage-collected shutdown of the first, causing the second one to
fail to bind the listening port.  Avoid the situation by setting
start_kdc=False, because there doesn't need to be a KDC running for
these tests anyway.  Also use create_user=False and create_host=False,
because those principals aren't necessary either.

ticket: 7977
Fix glob memory leak in GSS initialization

In loadConfigFiles, call globfree even if glob fails, since glob can
allocate memory and report partial results on failure.  Also
initialize globbuf before calling glob; this is not strictly required,
but hedges against hypothetical libc implementation bugs which could
leave globbuf.gl_pathc or globbuf.gl_pathv uninitialized on error.

ticket: 7981
Disallow unlocked iteration of hash databases

It's not clear whether unlocked iteration over a hash DB2 database
will omit unaffected entries if database additions or deletions occur
concurrently with the iteration.  Avoid this situation by disabling
unlocked iteration in the unlikely event that someone is still using a
hash database for their KDB.

ticket: 7977
Fix LDAP key data segmentation [CVE-2014-4345]

For principal entries having keys with multiple kvnos (due to use of
-keepold), the LDAP KDB module makes an attempt to store all the keys
having the same kvno into a single krbPrincipalKey attribute value.
There is a fencepost error in the loop, causing currkvno to be set to
the just-processed value instead of the next kvno.  As a result, the
second and all following groups of multiple keys by kvno are each
stored in two krbPrincipalKey attribute values.  Fix the loop to use
the correct kvno value.

CVE-2014-4345:

In MIT krb5, when kadmind is configured to use LDAP for the KDC
database, an authenticated remote attacker can cause it to perform an
out-of-bounds write (buffer overrun) by performing multiple cpw
-keepold operations.  An off-by-one error while copying key
information to the new database entry results in keys sharing a common
kvno being written to different array buckets, in an array whose size
is determined by the number of kvnos present.  After sufficient
iterations, the extra writes extend past the end of the
(NULL-terminated) array.  The NULL terminator is always written after
the end of the loop, so no out-of-bounds data is read, it is only
written.

Historically, it has been possible to convert an out-of-bounds write
into remote code execution in some cases, though the necessary
exploits must be tailored to the individual application and are
usually quite complicated.  Depending on the allocated length of the
array, an out-of-bounds write may also cause a segmentation fault
and/or application crash.

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

[ghudson@mit.edu: clarified commit message]
[kaduk@mit.edu: CVE summary, CVSSv2 vector]

ticket: 7980 (new)
target_version: 1.12.2
tags: pullup
Add regression test for LDAP key fencepost bug

ticket: 7980
In ksu, merge krb5_ccache_copy() and _restricted()

Other than whether or not they limit the creds it stores to the new
ccache based on the principal name of the client for whom the creds were
issued, there's no meaningful difference between what these two
functions do.  Merge them.
In ksu, don't stat() not-on-disk ccache residuals

Don't assume that ccache residual names are filenames which we can
stat() usefully.  Instead, use helper functions to call the library
routines to try to read the default principal name from caches, and
use whether or not that succeeds as an indication of whether or not
there's a ccache in a given location.

ticket: 7728
Use an intermediate memory cache in ksu

Instead of copying source or obtained creds into the target cache and
changing ownership if everything succeeds, copy them into a MEMORY:
cache and then, if everything succeeds, create the target cache as the
target user.

We no longer need to clean up the temporary ccache when exiting in
most error cases.

Use a fake principal name ("_ksu/_ksu@_ksu") as the primary holder of
the temporary cache so that we won't accidentally select it when we
make a subsequent call to krb5_cc_cache_match() (to be added in a
later patch) to find the target location where the creds should be
stored for use while running as the target user.
Make ksu respect the default_ccache_name setting

Move the logic for resolving and initializing a cache that we're
copying creds into out of krb5_ccache_copy(), and let the caller deal
with it.  Add a helper functions to select/resolve an output ccache in
the default location for the target user after we've switched to the
target user's privileges.  If the destination is a collection, take
care not to change which subsidiary is its primary, and reuse a
subsidiary cache if we can.  If the destination is not a collection,
append a unique value to its name to make a new ccache.

[ghudson@mit.edu: some changes to variable names and comments; move
responsibility for getting target ccache name from
resolve_target_ccache to main]

ticket: 7984 (new)
Copy config entries to the ksu target ccache

When we try to screen out expired creds while reading them from one
ccache to eventually store in another, also keep configuration entries.

ticket: 7986 (new)
Use more randomness for ksu secondary cache names

When generating a suffix to append to a ccache name that will hold the
credentials for a ksu-invoked process, instead of using integers
counting up from 1, use the result of base64-encoding six randomly-
generated octets.  Tweak the output alphabet just a bit to avoid using
'+' or '/' in the generated names, the latter of which could really
confuse things.
krb5-1.14 prerelease

Now that krb5-1.13 is branched, master is krb5-1.14 prerelease.
Fix GSS krb5 GSS_C_DELEG_FLAG ret_flags result

The krb5 gss_accept_sec_context could erroneously return
GSS_C_DELEG_FLAG in ret_flags if either:

* The token included the GSS_C_DELEG_FLAG but did not include at least
  28 bytes in the authenticator checksum.
* The initial token included the GSS_C_DELEG_FLAG but a DCE-style
  exchange was performed.

Fix both of these cases.

ticket: 7987 (new)
target_version: 1.13
tags: pullup
Make krb5_cc_new_unique create DIR: directories

When we use krb5_cc_new_unique to create a new cache in a directory
cache collection, we will fail if the directory doesn't exist yet.

Go ahead and preemptively create it, as we do during krb5_cc_resolve,
before attempting to create a new file under it.

ticket: 7988 (new)
target_version: 1.13
tags: pullup
Allow SPNEGO fallback to NTLM without mechlistMIC

For interoperability with Windows Server 2003 and earlier, loosen the
initiator's enforcement of RFC 4178's mechlistMIC requirement when
falling back to NTLMSSP.

[ghudson@mit.edu: rewrote commit message, added comment to NTLMSSP
OID]

ticket: 7975
target_version: 1.13
tags: pullup
Remove Windows NT "support"

We had some compatability shims to detect if the running system
was older than Windows 2000, that is, whether it was Windows NT.
Remove those checks, and the fallback behavior (which was to
fail early).

The checks were effected by the is_windows_2000() function, which,
despite the name, was actually checking for whether the running
OS was windows 2000 *or newer*.  That is, it was checking for whether
this was some truly ancient system such as Windows 98 or the original
Windows NT.  Such systems have been unsupported for a very long time,
so there is no need to retain this check.
Remove Windows 2000 support

Windows 2000 is long-gone.  Remove the is_windows_xp() function
that was checking whether we were running on XP or any newer system
(that is, whether we were running on Windows 2000) and simplify
conditional code as appropriate.

De-indent chunks that are no longer conditional, and add a
set of braces to clarify the nested conditional.
Remove the unused is_windows_vista()
Remove is_broken_wow64()

The issue worked around by this function would cause crashes at
runtime, as described by Microsoft's Article ID 960077.  That article
indicates that a hotfix was available, and it appears that that fix
has made it into a subsequent update for Windows Server 2003 SP2.
Since Windows XP SP2 is also listed as affected, I assume that
Windows XP SP3 also has the fix.

Since there are not believed to be any affected systems anymore,
it is safe to remove the workaround.
It looks like the windows hotfix (article ID 960077) for the crashes
caused by the underlying issue this function worked around
Remove does_retrieve_ticket_cache_ticket()

This helper queries (and caches) whether the
KERB_RETRIEVE_TICKET_CACHE_TICKET is supported in the
KERB_RETRIEVE_TKT_REQUEST structure.  The documentation of that
structure on MSDN states that the KERB_RETRIEVE_TICKET_CACHE_TICKET
flag is not available on Windows XP with SP1 and earlier, and
Windows Server 2003.  Those platforms are no longer supported
(most notably, there are newer service packs), so this code can
safely be removed.