Greg Hudson [Tue, 21 Feb 2012 18:57:44 +0000 (18:57 +0000)]
Fix kvno ASN.1 encoding interop with Windows RODCs
RFC 4120 defines the EncryptedData kvno field as an integer in the
range of unsigned 32-bit numbers. Windows encodes and decodes the
field as a signed 32-bit integer. Historically we do the same in our
encoder in 1.6 and prior, and in our decoder through 1.10. (Actually,
our decoder through 1.10 decoded the value as a long and then cast the
result to unsigned int, so it would accept positive values >= 2^31 on
64-bit platforms but not on 32-bit platforms.)
kvno values that large (or negative) are only likely to appear in the
context of Windows read-only domain controllers. So do what Windows
does instead of what RFC 4120 says.
Modify the trval output slightly so that the reference trval output
files don't containing trailing whitespace, to make them friendlier to
our git hooks. (The pkinit and ldap trval reference files now contain
a leading blank line, which isn't very elegant, but avoiding that
requires too much Makefile.in complexity.) Also correct a typo.
This is a cosmetic change to reintroduce some space characters that cff6ea939f061d17a5742a04b8eeb2905c1813dc removed, e.g. between the tag
and the length or short value.
Greg Hudson [Thu, 23 Jun 2011 04:13:38 +0000 (04:13 +0000)]
Work around glibc getaddrinfo PTR lookups
In krb5_sname_to_principal(), we always do a forward canonicalization
using getaddrinfo() with AI_CANONNAME set. Then, we do a reverse
canonicalization with getnameinfo() if rdns isn't set to false in
libdefaults.
Current glibc (tested with eglibc 2.11.1) has the arguably buggy
behavior of doing PTR lookups in getaddrinfo() to get the canonical
name, if hints.ai_family is set to something other than AF_UNSPEC.
This behavior defeats the ability to turn off rdns. Work around this
behavior by using AF_UNSPEC in krb5_sname_to_principal() from the
start, instead of starting with AF_INET and falling back. Specify
AI_ADDRCONFIG to avoid AAAA lookups on hosts with no IPv6 addresses.
When canonicalizing a principal, use AI_CANONNAME alone in the hint
flags for getaddrinfo, for two reasons. First, it works around a gnu
libc bug where getaddrinfo does a PTR lookup for the canonical name
(we tried to work around this in r24977 bug the addition of
AI_ADDRCONFIG caused the same problem as the use of AF_INET). Second,
an IPv4-only host should be able create a principal for an IPv6-only
host even if it can't contact the host.
This does result in extra AAAA queries in the common case (IPv4-only
host contacting IPv4-only service), which is unfortunate. But we need
to leave that optimization up to the platform at this point.
Greg Hudson [Tue, 22 May 2012 17:45:18 +0000 (13:45 -0400)]
Export gss_mech_krb5_wrong from libgssapi_krb5
Although there are few legitimate reasons to use gss_mech_krb5_wrong,
it's declared in the public header and exported in the Windows DLL.
So export it from the Unix library as well.
Tom Yu [Thu, 21 Jun 2012 16:51:11 +0000 (12:51 -0400)]
Try all history keys to decrypt password history
A database created prior to 1.3 will have multiple password history
keys, and kadmin prior to 1.8 won't necessarily choose the first one.
So if there are multiple keys, we have to try them all. If none of
the keys can decrypt a password history entry, don't fail the password
change operation; it's not worth it without positive evidence of
password reuse.
Tom Yu [Fri, 15 Jun 2012 18:13:35 +0000 (14:13 -0400)]
Null pointer deref in kadmind [CVE-2012-1013]
The fix for #6626 could cause kadmind to dereference a null pointer if
a create-principal request contains no password but does contain the
KRB5_KDB_DISALLOW_ALL_TIX flag (e.g. "addprinc -randkey -allow_tix
name"). Only clients authorized to create principals can trigger the
bug. Fix the bug by testing for a null password in check_1_6_dummy.
Tom Yu [Fri, 27 Apr 2012 22:40:21 +0000 (22:40 +0000)]
Use correct name-type in TGS-REQs for 2008R2 RODCs
Correctly set the name-type for the TGS principals to KRB5_NT_SRV_INST
in TGS-REQs. (Previously, only AS-REQs had the name-type set in this
way.) Windows Server 2008 R2 read-only domain controllers (RODCs)
insist on having the correct name-type for the TGS principal in
TGS-REQs as well as AS-REQs, at least for the TGT-forwarding case.
Thanks to Sebastian Galiano for reporting this bug and helping with
testing.
Appending "--" to the git checkout arguments appears to prevent it
from automatically creating a local branch from the remote. Also
correct the default git URL and clean up a spurious find warning.
(cherry picked from commit 4fc9c72e5d30c94399baf7069a0d0db25e940a68)
If krb5_server_decrypt_ticket_keytab doesn't find a key of the
appropriate enctype in an iterable keytab, it returns 0 (without
decrypting the ticket) due to a misplaced initialization of retval.
This bug causes kinit -k to claim "keytab entry valid" when it
shouldn't. Reported by mark@mproehl.net.
ticket: 7021
subject: Fix failure interval of 0 in LDAP lockout code
target_version: 1.10
tags: pullup
A failure count interval of 0 caused krb5_ldap_lockout_check_policy to
pass the lockout check (but didn't cause a reset of the failure count
in krb5_ldap_lockout_audit). It should be treated as forever, as in
the DB2 back end.
This bug is the previously unknown cause of the assertion failure
fixed in CVE-2011-1528.
ticket: 7003
subject: Fix month/year units in getdate
target_version: 1.10
tags: pullup
getdate strings like "1 month" or "next year" would fail some of the
time, depending on the value of stack garbage, because DSTcorrect()
doesn't set *error on success and RelativeMonth() doesn't initialize
error. Make DSTcorrect() responsible for setting *error in all cases.
ticket: 7000
subject: Exit on error in kadmind kprop child
target_version: 1.10
tags: pullup
When we fork from kadmind to dump the database and kprop to an iprop
slave, if we encounter an error in the child process we should exit
rather than returning to the main loop.
When using hmac-md5, the intermediate key length is the output of the
hash function (128 bits), not the input key length. Relevant if the
input key is not an RC4 key.
Tom Yu [Tue, 28 Jun 2011 22:11:51 +0000 (22:11 +0000)]
work around Dejagnu failure on modern Tcl
Modern releases of Tcl (8.5 and later?) require use the special
procedure "unknown" to implement some autoloading functionality.
Dejagnu replaces "unknown" with its own definition, without chaining
to the original version of "unknown". This causes "clock format
[clock seconds]" to fail while trying to load the "msgcat" Tcl
package.
Use "exec date" instead of "clock format [clock seconds]" to work
around this bug.
Fix the sole case in process_chpw_request() where a return could occur
without allocating the data pointer in the response. This prevents a
later free() of an invalid pointer in kill_tcp_or_rpc_connection().
Also initialize rep->data to NULL in process_chpw_request() and clean
up *response in dispatch() as an additional precaution.
ticket: 6870
subject: Don't reject AP-REQs based on PACs
target_version: 1.9.1
tags: pullup
Experience has shown that it was a mistake to fail AP-REQ verification
based on failure to verify the signature of PAC authdata contained in
the ticket. We've had two rounds of interoperability issues with the
hmac-md5 checksum code, an interoperability issue OSX generating
unsigned PACs, and another problem where PACs are copied by older KDCs
from a cross-realm TGT into the service ticket. If a PAC signature
cannot be verified, just don't mark it as verified and continue on
with the AP exchange.
Fix a conceptual bug in r24639: the intermediate key container length
should be the hash's output size, not its block size. (The bug did
not show up in testing because it is harmless in practice; MD5 has a
larger block size than output size.)
------------------------------------------------------------------------
r24639 | ghudson | 2011-02-16 17:52:41 -0500 (Wed, 16 Feb 2011) | 11 lines
ticket: 6869
subject: hmac-md5 checksum doesn't work with DES keys
target_version: 1.9
tags: pullup
krb5int_hmacmd5_checksum calculates an intermediate key using an HMAC.
The container for this key should be allocated using the HMAC output
size (which is the hash blocksize), not the original key size. This
bug was causing the function to fail with DES keys, which can be used
with hmac-md5 in PAC signatures.
ticket: 6852
subject: Make gss_krb5_set_allowable_enctypes work for the acceptor
target_version: 1.9.1
tags: pullup
With the addition of enctype negotiation in 1.7, a gss-krb5 acceptor
can choose an enctype for the acceptor subkey other than the one in
the keytab. If the resulting security context will be exported and
re-imported by another gss-krb5 implementation (such as one in the
kernel), the acceptor needs a way to restrict the set of negotiated
enctypes to those supported by the other implementation. We had that
functionality for the initiator already in the form of
gss_krb5_set_allowable_enctypes; this change makes it work for the
acceptor as well.
ticket: 6839
subject: handle MS PACs that lack server checksum
target_version 1.9
tags: pullup
Apple Mac OS X Server's Open Directory KDC issues MS PAC like
authorization data that lacks a server checksum. If this checksum is
missing, mark the PAC as unverfied, but allow
krb5int_authdata_verify() to succeed. Filter out the unverified PAC
in subsequent calls to krb5_authdata_get_attribute(). Add trace
points to indicate where this behavior occurs.
Thanks to Helmut Grohne for help with analysis. This bug is also
Debian Bug #604925:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604925
This change should also get backported to krb5-1.8.x.
Tom Yu [Sat, 4 Dec 2010 05:11:04 +0000 (05:11 +0000)]
SA-2010-007 Checksum vulnerabilities (CVE-2010-1324 and others)
Apply patch for MITKRB5-SA-2010-007.
Fix multiple checksum handling bugs, as described in:
CVE-2010-1324
CVE-2010-1323
CVE-2010-4020
CVE-2010-4021
* Return the correct (keyed) checksums as the mandatory checksum type
for DES enctypes.
* Restrict simplified-profile checksums to their corresponding etypes.
* Add internal checks to reduce the risk of stream ciphers being used
with simplified-profile key derivation or other algorithms relying
on the block encryption primitive.
* Use the mandatory checksum type for the PKINIT KDC signature,
instead of the first-listed keyed checksum.
* Use the mandatory checksum type when sending KRB-SAFE messages by
default, instead of the first-listed keyed checksum.
* Use the mandatory checksum type for the t_kperf test program.
* Use the mandatory checksum type (without additional logic) for the
FAST request checksum.
* Preserve the existing checksum choices (unkeyed checksums for DES
enctypes) for the authenticator checksum, using explicit logic.
* Ensure that SAM checksums received from the KDC are keyed.
* Ensure that PAC checksums are keyed.
Make krb5_dbe_def_search_enctype skip key data entries with invalid
enctypes instead of erroring out on them. We had this behavior prior
to 1.8 (more by accident than by design), but it changed as a
side-effect of r23599.
ticket: 6768
subject: GSSAPI forwarded credentials must be encrypted in session key
target_version: 1.8.4
tags: pullup
When IAKERB support was added, the krb5_mk_req checksum function
gained access to the send subkey. This caused GSSAPI forwarded
credentials to be encrypted in the subkey, which violates RFC 4121
section 4.1.1 and is not accepted by Microsoft's implementation.
Temporarily null out the send subkey in the auth context so that
krb5_mk_ncred uses the session key instead.
ticket: 6797
subject: CVE-2010-1322 KDC uninitialized pointer crash in authorization data handling (MITKRB5-SA-2010-006)
tags: pullup
target_version: 1.8.4
When the KDC receives certain TGS-REQ messages, it may dereference an
uninitialized pointer while processing authorization data, causing a
crash, or in rare cases, unauthorized information disclosure, ticket
modification, or execution of arbitrary code. The crash may be
triggered by legitimate requests.
Correctly implement the filtering of authorization data items to avoid
leaving uninitialized pointers when omitting items.
kdb5_stash() contains its own kdb5_db_open() call (because it doesn't
use util_context for some reason), which didn't work with the LDAP
back end because LDAP doesn't recognize KRB5_KDB_SRV_TYPE_OTHER. As a
minimal fix, change that to KRB5_KDB_SRV_TYPE_ADMIN to be consistent
with open_db_and_mkey()--see also r18736.
ticket: 6751
subject: Allow Microsoft HMAC-MD5 checksum types to use non-RC4 keys
target_version: 1.8.3
tags: pullup
In PAC signatures, the hmac-md5 checksum type can be used with AES
keys. Make this work by removing the enc field from the hmac-md5 and
md5-hmac checksum types, and adding a check in
krb5int_hmacmd5_checksum() for a null key or a key which is longer
than the hash block size (64 bytes for MD5). The checksum algorithm
only uses the key bits; it does invoke the cipher.
The checksum type names are kind of wrong, but we'll leave them alone
for compatibility. The descriptions are updated.
gss_krb5int_lib_init was adding the generic GSS error table (again)
instead of the krb5 error table, which could lead to crashes on
library unload. This bug was introduced in krb5 1.7; the fix is also
applicable there.
Patch from Leonardo Chiquitto <leonardo.lists@gmail.com>.
ticket: 6744
subject: only test t_locate_kdc if known-good DNS name is present
target_version: 1.8.3
tags: pullup
Running "make check" while offline or on a firewalled network may
result in failure in lib/krb5/os because the invocation of
t_locate_kdc requires that the DNS servers for ATHENA.MIT.EDU be
reachable. Autodetect DNS utilities "dig" and "nslookup", and use
them to check for existence of the known-good DNS name. Also
parameterize the test so that the known-good DNS name can be
overridden on the make command line.
ticket: 6740
subject: kadmin ktadd may display wrong name of default keytab
target_version: 1.8.2
tags: pullup
kadmin's ktadd (and ktrem) displays WRFILE:/etc/krb5.keytab whenever
it uses the default keytab, even if the default has been overridden
(e.g. by KRB5_KTNAME). Use krb5_kt_get_name to get the correct name
of the default cache instead of displaying the string we think was
used to open it.
Stop checking the current time against the context expiration time in
the message wrap/unwrap functions in the krb5 GSS mech. Heimdal
doesn't do it, and it generally results in poor app behavior when a
ticket expires. In exchange, it doesn't provide much security benefit
since it's not enforced across the board--for example, ssh sessions
can persist beyond ticket expiration time since they don't use GSS to
wrap payload data.
ticket: 6734
subject: FAST negotiation could erroneously succeed
target_version: 1.8.2
tags: pullup
When FAST negotiation is performed against an older KDC
(rep->enc_part2->flags & TKT_FLG_ENC_PA_REP not set),
krb5int_fast_verify_nego did not set the value of *fast_avail, causing
stack garbage to be used in init_creds_step_reply. Initialize
*fast_avail at the beginning of the function per coding practices.
ticket: 6730
subject: kdc_tcp_ports not documented in kdc.conf.M
target_version: 1.8.2
tags: pullup
The kdc.conf setting kdc_tcp_ports was not documented in kdc.conf.M,
though it was documented in doc/admin.texinfo. Copy text from there
for now. The setting defaults to an empty string at the moment,
causing the KDC to not listen on TCP by default, confusing some users.
Changing this behavior is a separate issue.
When parsing a KDC or admin server string, allow the name or address
to be enclosed in brackets so that IPv6 addresses can be represented.
(IPv6 addresses contain colons, which look like port separators.)
ticket: 6718
subject: Make KADM5_FAIL_AUTH_COUNT_INCREMENT more robust with LDAP
target_version: 1.8.2
tags: pullup
In krb5_ldap_put_principal, use krb5_get_attributes_mask to determine
whether krbLoginFailedCount existed on the entry when it was
retrieved. If it didn't exist, don't try to use LDAP_MOD_INCREMENT,
and don't assert an old value when not using LDAP_MOD_INCREMENT.
Also, create the krbLoginFailedCount attribute when creating new
entries. This allows us to use LDAP_MOD_INCREMENT during the first
failed login (if the server supports it), avoiding a race condition.
ticket: 6693
subject: Fix backwards flag output in krb5_init_creds_step()
tags: pullup
target_version: 1.8.1
krb5_init_creds_step() is taken from Heimdal, which sets *flags to 1
for "continue" and 0 for "stop". Unfortunately, we got it backwards
in 1.8; fix it for 1.8.1.
ticket: 6689
target_version: 1.8.1
tags: pullup
subject: krb5_typed_data not castable to krb5_pa_data on 64-bit MacOSX
Move krb5_typed_data to krb5.hin from k5-int-pkinit.h because
krb5int_fast_process_error was assuming that it was safe to cast it to
krb5_pa_data. It's not safe to do the cast on 64-bit MacOSX because
krb5.hin uses #pragma pack on that platform.
ticket: 6687
subject: Change KRB5_AUTHDATA_SIGNTICKET from 142 to 512
target_version: 1.8.1
tags: pullup
KRB5_AUTHDATA_SIGNTICKET, originally a Heimdal authorization data
type, was used to implement PAC-less constrained delegation in krb5
1.8. Unfortunately, it was found that Microsoft was using 142 for
other purposes, which could result in a ticket issued by an MIT or
Heimdal KDC being rejected by a Windows Server 2008 R2 application
server. Because KRB5_AUTHDATA_SIGNTICKET is only used to communicate
among a realm's KDCs, it is relatively easy to change the number, so
MIT and Heimdal are both migrating to a new number. This change will
cause a transitional interoperability issue when a realm mixes MIT
krb5 1.8 (or Heimdal 1.3.1) KDCs with MIT krb5 1.8.1 (or Heimdal
1.3.2) KDCs, but only for constrained delegation evidence tickets.
ticket: 6685
target_version: 1.8.1
subject: handle NT_SRV_INST in service principal referrals
Handle NT_SRV_INST in service principal cross-realm referrals, as
Windows apparently uses that instead of NT_SRV_HST for at least some
service principals.
ticket: 6676
subject: Ignore improperly encoded signedpath AD elements
target_version: 1.8.1
tags: pullup
We have some reason to believe Microsoft and Heimdal are both using
the authdata value 142 for different purposes, leading to failures in
verify_ad_signedpath(). For better interoperability, treat such
tickets as unsigned, rather than invalid.
ticket: 6668
subject: Two problems in kadm5_get_principal mask handling
target_version: 1.8
tags: pullup
KADM5_MOD_NAME was being applied to entry->principal instead of
entry->mod_name. KADM5_MKVNO was not being applied to entry->mkvno.
Patch from Marcus Watts <mdw@umich.edu>.
Fix two unrelated problems in SPNEGO which don't crop up with the krb5
mechanism.
1. The third call to spnego_init_accept_context uses faulty logic to
determine if the exchange is complete, preventing a third mech token
from being sent to the acceptor if no MIC exchange is required.
Follow the logic used in the second call (in init_ctx_nego), which is
correct.
2. If the acceptor selects a mech other than the optimistic mech, it
sets sc->mic_reqd to 1 whether or not the selected mech supports MICs
(which isn't known until the mech completes). Most code outside of
handle_mic checks sc->mic_reqd along with (sc->ctx_flags &
GSS_C_INTEG_FLAG), but the code in acc_ctx_call_acc neglected to do
so, so it could improperly delegate responsibility for deciding when
the negotiation was finished to handle_mic--which never gets called if
(sc->ctx_flags & GSS_C_INTEG_FLAG) is false. Fix acc_ctx_call_acc to
check sc->ctx_flags so that mechs which don't support integrity
protection can complete if they are selected non-optimistically.
projects / thirdparty / krb5.git / log
