Reported to Heimdal by Michał Kępień <michal@isc.org>.
From the report:
Acknowledgement
---------------
This flaw was found while working on addressing ZDI-CAN-12302: ISC BIND
TKEY Query Heap-based Buffer Overflow Remote Code Execution
Vulnerability, which was reported to ISC by Trend Micro's Zero Day
Initiative.
We were losing and leaking the reason for which kdc_check_flags() was
rejecting any S4U requests, yielding incomplete error messages.
The issue is that kdc_check_flags() wants to check the client and server
principals in the input state structure, but doesn't know about
impersonated principal name, and so we want to pass it a state structure
that has the impersonated instead of the impersonator client name. This
is a bad design, but I'm ignoring that for now and just fixing this one
leak.
The TGS will issue referrals based on [domain_realm] mappings.
With this change the TGS will also issue referrals based on HDB entry
aliases.
The TGS needed no changes for this, only support in lib/hdb was missing.
All we had to do was return HDB_ERR_WRONG_REALM from hdb_fetch_kvno()
when the given principal is an alias and its canonical name's realm is
different from the alias'.
This feature is important because the KDC currently does not re-read
krb5.conf and must be restarted for changes to e.g., [domain_realm]
mappings to take effect. As well, making krb5.conf changes to all the
KDCs for a realm would need to be arranged. But with aliases in the
HDB, these problems go away.
Relatedly, we should really have an option to store the KDC's entire
configuration in the HDB...
Futures:
- Add support for aliasing of entire namespaces via HDB aliases with
WELLKNOWN namespace name forms. This will round out domain-to-realm
mapping configuration support via HDB.
Deleting an alias causes the HDB_entry_alias entry value encoding to be
written to the iprop log, which later cannot be decoded as an HDB_entry.
Meanwhile, the alias is removed from the HDB but not from the list of
aliases in the canonical principal's HDB entry.
This commit makes deletion of alias names an error.
Sort of. It already knew.
We have a mess where new things get sent to the server as
KRB5_TL_EXTENSION, but old things get sent to the client as whatever
appropriate KRB5_TL we have, and... we call perform_tl_data() on all TL,
but we don't remove unmodified TL on the client side, and...
Anyways. This commit is a band-aid, but it works.
Fix _gss_spnego_set_sec_context_option() to return GSS_S_UNAVAILABLE if no
context handle is provided, so that mechglue will skip to the next mechanism.
There are no globally settable options on SPNEGO itself.
Fixes: #803
When generating an AS-REQ, the TGS signature was incorrectly generated using
the server key, which would fail to validate if the server was not also the
TGS. Fix this.
Patch from Isaac Bourkis <iboukris@gmail.com>.
The principal in the PAC_LOGON_NAME buffer is expected to match the client name
in the ticket. Previously we were setting this to the canonical client name,
which would have broken PAC validation if the client did not request name
canonicalization
split_spec() should free output parameters if it fails. This was not a leak in
practice because its single caller cleaned up anyway, but cleaning up for good
hygiene.
RFC4120 says KRB5KDC_ERR_SUMTYPE_NOSUPP should be returned if the KDC does not
support a given checksum type. Return this instead of KRB5_PROG_SUMTYPE_NOSUPP
by introducing a new wrapper function, _kdc_verify_checksum().
Make keyed checksums mandatory when generating and verifying checksums, with
the following exceptions:
* the checksum is being generated or verified as part of encrypting data for
a legacy (DES) encryption type
* the KRB5_CRYPTO_FLAG_ALLOW_UNKEYED_CHECKSUM flag was set on the crypto
context, used to allow unkeyed checksums in krb5 authenticators
By making unkeyed checksums opt-in, we eliminate a class of potential
vulnerabilities where callers could pass unkeyed checksums.
Any code that uses the mandatory checksum type for a given non-legacy
encryption type should not be affected by this change. It could potentially
break, say, a client trying to do FAST with DES keys but, that should not be
supported (because FAST KDCs also support AES).
Closes: #835
Split Windows PAC signing and verification logic, as the signing has to be when
the ticket is ready.
Create sign and verify the PAC KDC signature if the plugin did not, allowing
for S4U2Proxy to work, instead of KRB5SignedPath.
Use the header key to verify PAC server signature, as the same key used to
encrypt/decrypt the ticket should be used for PAC server signature, like U2U
tickets are signed witht the tgt session-key and not with the longterm key,
and so krbtgt should be no different and the header key should be used.
Lookup the delegated client in DB instead of passing the delegator DB entry.
Add PAC ticket-signatures and related functions.
Note: due to the change from KRB5SignedPath to PAC, S4U2Proxy requests
against new KDC will not work if the evidence ticket was acquired from
an old KDC, and vide versa.
Closes: #767
KRB5SignedPath was a Heimdal-specific authorization data element used to
protect the authenticity of evidence tickets when used in constrained
delegation (without a Windows PAC).
Remove this, to be replaced with the Windows PAC which itself now supports
signing the entire ticket in the TGS key.
