Normally when FAST is used with a TGS-REQ, the armor key is implicitly
derived from the TGT rather than armor being explicitly present, as for
AS-REQs. However, Windows allows a TGS-REQ to be explicitly armored with
a computer's TGT, so that the armor key also depends on the ticket
session key.
This is used for compound identity, where the computer's group
membership and claims are added to the PAC of the resulting ticket.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Samba includes the user's long-term credentials (encrypted in the AS reply key)
to allow legacy authentication protocols such as NTLM to work even if the
pre-authentication mechanism replaced the reply key (as PKINIT does).
Samba also needs to know whether the client explicitly requested a PAC be
included (or excluded), in order to defer PAC exclusion until a service ticket
is issued (thereby avoiding a name binding attack if the user is renamed
between TGT and service ticket issuance).
References:
https://bugzilla.samba.org/show_bug.cgi?id=11441https://bugzilla.samba.org/show_bug.cgi?id=14561Closes: #864
Original authors:
- Joseph Sutton <josephsutton@catalyst.net.nz>
- Andrew Bartlett <abartlet@samba.org>
- Stefan Metzmacher <metze@samba.org>
This lets us call it from Samba.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
[abartlet@samba.org Similar to Samba commit 3bdce12789af1e7a7aba56691f184625a432410d
but also fixed for caller in Heimdal windc plugin tests]
Previously, if left==right==A1_HEADER_LEN(tos), this would read past the
end of the template array. Now we treat [left, right) as a half-open
interval and no longer try to read from 'right'.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Always require a strengthen key to be used if GSS pre-authentication is used
within FAST. TRhis avoids a MITM attack that could result in unintended
privilege escalation, should a KDC add additional positive authorization data
from the armor ticket to the issued ticket.
An upcoming revision of the draft will reflect this.
Import KDC FAST from Apple's Heimdal-597.121.1, adding support for:
- PA-ENC-CHALLENGE
- reply key strengthening
- FAST authentication in TGS
kuser: Apple sync (squash)
krb5_init_creds_store_config/krb5_init_creds_warn_user in kinit
Sync with most changes in AS/TGS client from Apple's Heimdal-597.121.1
(opensource.apple.com).
Changes include:
- FAST support in TGS client
- Refactored pre-auth client to be more easily extensible
- Pin KDC host and AD site name in API calls
Note the completely refactored TGS client loop is not imported as that was
considered too intrusive.
This reverts commit 24a7a82e82.
After further discussion in #863, the alignment (which differs according to
info buffer type) should be handled by the caller.
Decoding a FAST request will only give us the FastOptions flags that are
explicitly declared in the ASN1 source. This meant that the check for
unsupported mandatory options would never succeed, and an unsupported
option would go undetected.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
The reply structure was not being zero-initialised in all cases, leading
to crashes or possible heap corruption on error paths when we later
freed it.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Setting `dns_lookup_realm = false` in `[libdefaults]` and setting name
canon rules that force the empty realm causes destination-TGT delegation
to break because the client doesn't know the service's realm.
Because MIT and Heimdal check that the (unauthenticated plaintext)
sname/realm of the Ticket in the KDC reply matches the sname/srealm in
the enc-part of the KDC reply, we know we can trust the realm of the
ticket found in the ccache. So use that.
Setting `dns_lookup_realm = false` in `[libdefaults]` and setting name
canon rules that force the empty realm causes destination-TGT delegation
to break because the client doesn't know the service's realm.
Because MIT and Heimdal check that the (unauthenticated plaintext)
sname/realm of the Ticket in the KDC reply matches the sname/srealm in
the enc-part of the KDC reply, we know we can trust the realm of the
ticket found in the ccache. So use that.
Samba3 sends an AP-REQ, rather than 8003, checksum in a Kerberos inital context
token. This regressed in #835 as we forgot to set the
KRB5_CRYPTO_FLAG_ALLOW_UNKEYED_CHECKSUM flag before processing the AP-REQ
checksum in this path.
SQLite3 defaults to 0644 unless overridden, relying on the process'
umask to make that tighter.
Our in-tree SQLite3 uses 0600 as the permissions for DB files it
creates.
Out-of-tree builds of SQLite3 probably get the 0644 default.
We can't change the umask in libraries -- it's not thread-safe.
So this commit changes the SCC ccache type's default ccname to include
an intermediate directory which is created with `mkdir(2)` with
permissions set to 0700, then it chmods the DB file to 0644.
The in-tree SQLite3 is used for HDB and ccache -- these should have
0600 permissions.
Of course, if we're using an out-of-tree SQLite3, then we need to rely
on the process' umask, but we use SQLite3 in libraries, where we can't
set the umask...
What to do?
TBD:
- On Windows: nothing to do.
- On Unix: if SQLite3 is out of tree then [v]fork() to create the
connection then close, then connect again after??
Or... maybe make sure to create an intermediate directory with 0700
permissions?
'uuid' is seen as an 'unsigned char*', thus '*uuid' is an 'unsigned char' where size is 1.
This solves a problem where two KCM ccaches's uuid have the same first byte hides each other.
What we observe:
* A user cannot discover tickets with (klist -l) but can access it with it's name
* The 'rpc.gssd' daemon is doing the same kind of pattern but using GSS calls (gss_acquire_cred)
Whet GDB told us:
* The 'kcm_ccache_get_uuids' is okay, all ccache are really present
* The 'kcm_ccache_resolve_by_uuid' is buggy, it only compare the first byte of each uuid.
Which may be the same as the one we're seeking. Selected ccache that will be, most probably, filtered-out afterward with a call to 'kcm_access'.
This leads to 'KRB5_FCC_NOFILE' errors while the uuid is correct.
Similar calls may be present.
This reverts commit 936017e4d6,
Samba is starting to protect against bi-di attacks and the starting point
is to require that input files be fully UTF-8. In 2021 this is a reasonable
starting point anyway.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Although not required to address bad code generation in
some versions of gcc 9 and 10, a coding style that requires
explicit comparison of the result to zero before use is
both clearer and would have avoided the generation of bad
code.
This change converts all use of cmp function usage from
```
if (strcmp(a, b) || !strcmp(c, d)) ...
```
to
```
if (strcmp(a, b) != 0 || strcmp(c, d)) == 0
```
for all C library cmp functions and related:
- strcmp(), strncmp()
- strcasecmp(), strncasecmp()
- stricmp(), strnicmp()
- memcmp()
Change-Id: Ic60c15e1e3a07e4faaf10648eefe3adae2543188
As documented in Russell O'Connor's blog, Heimdal when compiled with
some versions of gcc 9 and 10 would generate incorrect behaviors from
_gssapi_verify_mic_arcfour(), _gssapi_unwrap_arcfour(),
_gssapi_unwrap_iov_arcfour() and _gssapi_unwrap_iov_arcfour().
As a result of the bug, code of the form
if (memcmp(a, "\x00\x00\x00\x00"))
and
cmp = memcmp(a, "\x00\x00\x00\x00")
will be compiled as if it were written as
if (strcmp(a, "\x00\x00\x00\x00"))
and
cmp = strcmp(a, "\x00\x00\x00\x00")
but not
if (memcmp(a, "\x00\x00\x00\x00") != 0)
and
cmp = (memcmp(a, "\x00\x00\x00\x00") != 0)
Bad code is generated whenever one of the parameters to memcmp()
is a constant with at least one NUL in the first four octets and
the return value is used immediated without a boolean comparison.
The gcc bug 95189 has since been fixed.
This change applies a defensive programming technique to avoid
the broken code generation.
Change-Id: I1db2a561735317cb6cac66a0ec9caf5443e65e03
Link: https://r6.ca/blog/20200929T023701Z.html
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
Reported-by: Buck Huppmann (buckh@pobox.com) <buckh@pobox.com>
ad3acc2aef ("lib/gssapi/krb5:
implement gss_[un]wrap_iov[_length] with arcfour-hmac-md5")
introduced a duplicate block of code.
This change removes the unnecessary code duplication.
Change-Id: I557c590aea51b73dc25d6ce4be4ea84b9dfadd9f
krb5tgs.c: In function ‘_kdc_tgs_rep’:
krb5tgs.c:1785:25: warning: ‘header_key’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1785 | &tkey_check->key, &tkey_check->key, tgt, &kdc_issued, &mspac);
| ^~~~~~~~~~~~~~~~
krb5tgs.c:2302:10: note: ‘header_key’ was declared here
2302 | Key *header_key;
| ^~~~~~~~~~
On Ubuntu 20.04 in a default Heimdal build with
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
The compiler doesn't trust that *header_key = tkey; is always
executed in tgs_parse_request() for ret == 0.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
This reverts commit e27e056b45.
e27e056b45 was needed mainly for ENOTSUP.
ENOTSUP is not available in older C run-times.
Also, lib/roken has wrappers for the CRT allocator, but we don't need
those in lib/asn1 because all the functions generated by the compiler
effectively encapsulate the corresponding DLL's CRT's allocator.
This will be followed by a change to not use ENOTSUP.
The plugin interfaces were originally implemented for use on
Unix where KRB5_CALLCONV, HEIM_CALLCONV and similar are defined
as nothing. However, on 32-bit Windows the calling convention
matters and executing a __stdcall function through a __cdecl
function pointer will result in failures.
This change updates the krb5plugin_windc, krb5plugin_service_locate,
krb5plugin_send_to_kdc plugins to specify the KRB5_CALLCONV for
functions. This brings the plugins into compliance with the
heim_plugin_common interface requirement that init() and fini()
use the platform specified HEIM_CALLCONV.
The krb5-plugin(7) man page is updated and the lib/krb5/test_plugin
test is also fixed.
With this change all tests pass on 32-bit Windows.
Change-Id: Ic9d2e1285c9c179e3898dc9d071ed092bcddc406
