This has no real effect, but make things more clear
and matches the pattern for krb5_sendto_context().
Signed-off-by: Stefan Metzmacher <metze@samba.org>
This matches krb5_init_creds_step() from MIT. The only
difference is the type 'krb5_realm' (Heimdal) vs. 'krb5_data' (MIT).
krb5_error_code KRB5_CALLCONV
krb5_init_creds_step(krb5_context context,
krb5_init_creds_context ctx,
krb5_data *in,
krb5_data *out,
krb5_data *realm,
unsigned int *flags);
NOTE: commit 1cdc9d5f3c
"krb5: export krb5_init_creds_step()" exported
krb5_init_creds_step() the first time, but that's
not in any released version, so it should be fine
to fix up the prototype in order to make the
function actually useful for external callers.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
It should not return pointers to the internal state,
this matches the way the krb5_init_creds_step() works in MIT.
NOTE: commit 1cdc9d5f3c
"krb5: export krb5_init_creds_step()" exported
krb5_init_creds_step() the first time, but that's
not in any released version, so it should be fine
to change the behavior as there can't be any
external users of the function.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
_krb5_fast_anon_pkinit_step() should not set
KRB5_INIT_CREDS_STEP_FLAG_CONTINUE if it doesn't generate any output.
And krb5_init_creds_step() needs to return if
_krb5_fast_anon_pkinit_step() returned with
KRB5_INIT_CREDS_STEP_FLAG_CONTINUE set.
As that means the recursive call to krb5_init_creds_step()
generated output that should be send to a KDC and the
KDC response if needed as input for the next step.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
The current prototype of krb5_init_creds_step() is completely
useless as the caller has no way to know the destination
realm for the out blob.
The only internal caller of krb5_init_creds_step()
passes hostinfo=NULL and this commit makes it more obvious that hostinfo
is always NULL.
NOTE: commit 1cdc9d5f3c
"krb5: export krb5_init_creds_step()" exported
krb5_init_creds_step() the first time, but that's
not in any released version, so it should be fine
to fix up the prototype.
The aim is to remove hostinfo from the krb5_init_creds_step() internals
completely and move krb5_init_creds_step() to a useful prototype
where it returns the destination realm for the out packet.
Which means the prototype will mostly match the one MIT is using:
krb5_error_code KRB5_CALLCONV
krb5_init_creds_step(krb5_context context,
krb5_init_creds_context ctx,
krb5_data *in,
krb5_data *out,
krb5_data *realm,
unsigned int *flags);
Follow up patches demonstrate that the hostinfo related code
in pk_verify_host() is actually dead code as all layers
just passed down the NULL value from krb5_init_creds_get().
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Heimdal's HDB plugin interface, and hence Samba's KDC that depends upon
it, doesn't work on 32-bit builds due to structure fields being arranged
in the wrong order. This problem presents itself in the form of
segmentation faults on 32-bit systems, but goes unnoticed on 64-bit
builds thanks to extra structure padding absorbing the errant fields.
This commit reorders the HDB plugin structure fields to prevent crashes
and introduces a common macro to ensure every plugin presents a
consistent interface.
Samba BUG: https://bugzilla.samba.org/show_bug.cgi?id=15110
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Record when a CHOICE field is promoted from IMPLICIT to EXPLICIT and convey
this in the ASN.1 compiler's JSON output, so that other tools (e.g. which have
a representation isomorphic to the original ASN.1) may use it.
While the local stack pointers could be thought of as "only"
numbers that are not invalidated by the memory they point at
being freed, any use of the pointer after the free is undefined
and so warned about (at best).
gcc version 12.2.1 20220819 (Red Hat 12.2.1-1) (GCC)
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
We can't rely on having every KDC support FAST and should still
support S4U2Self against such a KDC.
We also have the order of the PA-DATA elements "corrected",
KRB5_PADATA_TGS_REQ followed by KRB5_PADATA_FX_FAST and
finally KRB5_PADATA_FOR_USER. While the inner PA-DATA
only contains KRB5_PADATA_FOR_USER.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=15002
Signed-off-by: Stefan Metzmacher <metze@samba.org>
This is needed when a service provides support for newer entry.etypes
without having a key for that encryption type yet.
It is triggered with svc_use_strongest_session_key=TRUE.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
As described by the C standard, __func__ is a variable, not a macro.
Hence this #ifndef check does not work as intended, and only serves to
unconditionally disable __func__. A nonoperating __func__ prevents
cmocka operating correctly, so remove this definition.
Samba BUG: https://bugzilla.samba.org/show_bug.cgi?id=15134
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Change-Id: Ieac3937b9e86f39e84c0c056ffd649e44b292099
On systems where 'unsigned long' is 32-bits and the 'size'
parameter is set to 8 and the bytes are:
0x78 0x00 0x00 0x00 0x00 0x00 0x00 0x00
When 'i' becomes 4 'v' will be 0 again. As 'unsigned long' is only
able to hold 4 bytes.
Change the type of 'v' from 'unsigned long' to 'uint64_t' which
matches the type of the output parameter 'value'.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
CVE: CVE-2022-42898
Samba-BUG: https://bugzilla.samba.org/show_bug.cgi?id=15203
Heimdal's ASN.1 compiler generates code that allows specially
crafted DER encodings of CHOICEs to invoke the wrong free function
on the decoded structure upon decode error. This is known to impact
the Heimdal KDC, leading to an invalid free() of an address partly
or wholly under the control of the attacker, in turn leading to a
potential remote code execution (RCE) vulnerability.
This error affects the DER codec for all CHOICE types used in
Heimdal, though not all cases will be exploitable. We have not
completed a thorough analysis of all the Heimdal components
affected, thus the Kerberos client, the X.509 library, and other
parts, may be affected as well.
This bug has been in Heimdal since 2005. It was first reported by
Douglas Bagnall, though it had been found independently by the
Heimdal maintainers via fuzzing a few weeks earlier.
We later subtract 8 when calculating the length of the output message
buffer. If padlength is excessively high, this calculation can underflow
and result in a very large positive value.
Now we properly constrain the value of padlength so underflow shouldn't
be possible.
Samba BUG: https://bugzilla.samba.org/show_bug.cgi?id=15134
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
If len_len is equal to total_len - 1 (i.e. the input consists only of a
0x60 byte and a length), the expression 'total_len - 1 - len_len - 1',
used as the 'len' parameter to der_get_length(), will overflow to
SIZE_MAX. Then der_get_length() will proceed to read, unconstrained,
whatever data follows in memory. Add a check to ensure that doesn't
happen.
Samba BUG: https://bugzilla.samba.org/show_bug.cgi?id=15134
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
By decrementing 'pad' only when we know it's safe, we ensure we can't
stray backwards past the start of a buffer, which would be undefined
behaviour.
In the previous version of the loop, 'i' is the number of bytes left to
check, and 'pad' is the current byte we're checking. 'pad' was
decremented at the end of each loop iteration. If 'i' was 1 (so we
checked the final byte), 'pad' could potentially be pointing to the
first byte of the input buffer, and the decrement would put it one
byte behind the buffer.
That would be undefined behaviour.
The patch changes it so that 'pad' is the byte we previously checked,
which allows us to ensure that we only decrement it when we know we
have a byte to check.
Samba BUG: https://bugzilla.samba.org/show_bug.cgi?id=15134
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
