This way if anything _does_ write to it, it has the opportunity to be
caught by SIGSEGV, by having zero_ivec in a .rodata segment mapped
read-only.
fix https://github.com/heimdal/heimdal/issues/1135
The struct _krb5_key_type.type is krb5_enctype. Cast it to
krb5_keytype before assigning to the 'krb5_keytype *keytype'
output variable to avoid a warning from Clang 1500 on Darwin.
decrypt_internal_derived(), decrypt_internal_enc_then_cksum(),
decrypt_internal(), and decrypt_internal_special() execute the
following pattern where 'p' is an allocation of size 'len'
l = len - n
memmove(p, p + n, l);
result->data = realloc(p, l);
if (result->data == NULL && l != 0) {
free(p);
return krb5_enomem(context);
}
result->length = l;
which when compiled by gcc 13.0.1-0.12.fc38 or gcc-13.0.1-0.13.fc39
generates the following warning
warning: pointer 'p' may be used after 'realloc' [-Wuse-after-free]
The C language specification indicates that it is only safe to free()
the pointer passed to realloc() if errno is set to ENOMEM. Yet the
warning is generated by the following pattern
l = len - n
memmove(p, p + n, l);
errno = 0;
result->data = realloc(p, l);
if (result->data == NULL && l != 0) {
if (errno == ENOMEM)
free(p);
return krb5_enomem(context);
}
result->length = l;
The value of performing the realloc() is questionable. realloc()
in many cases will need to perform a second allocation of the
smaller size and then perform a memcpy() which will slow down
the operation without saving much memory. The allocation is already
very small.
This change avoids the warning by removing the realloc() entirely.
Now that ETYPE_xxx names are macros to the KRB5_ENCTYPE_xxx
symbols there is no longer a need to cast to (krb5_enctype).
Change-Id: Ib561f6e45346abac7a53eb1db0bfef60ee3bcb74
AES256 and AES128 are newer enctypes because they are officially
specified in RFC4120 and RFC8009, while enctypes not officially
specified since RFC4120 are considered older. This function differs from
older_enctype() in that it does not report unknown or non-existent
enctypes as being 'newer'.
Signed-off-by: Joseph Sutton <josephsutton@catalyst.net.nz>
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
Add unkeyed checksum types for SHA-256, SHA-384 and SHA-512, for future
internal use. They are assigned private (negative) checksum types and must
never appear in cleartext on the wire.
When we have an underlying iovec encryption function, use iovecs for
checksum-then-encrypt alogrithms in decrypt_iov_ivec, rather than
coalescing iovecs into a single memory buffer.
Add a verify operation for this checksum. If a verify operation isn't
defined, then the verify_checksum code has to dynamically allocate and
free a block of memory for the computed checksum, which can be a
significant overhead when performing bulk data encryption.
Add a encrypt_iov function pointer to all of our encryption types
which can be used to implement an iovec based encryption routine.
Modify krb5_encrypt_iov so that it calls the iovec based routine
if it is available.
Use the iovec checksum routines in krb5_encrypt_iov_ivec. This
still marshalls all of the iovecs together to perform the encryption
operation, but this change halves the amount of time spent on
data marshalling in this function.
When we decide we need to zero the padding iovec, do so with 0, not
with the length that we've determined.
This had no effect because we zero the padding properly later, but it
should be fixed, so that things still work when the later memset() goes
away.
So that we can eventually use iovec hashes with encrypt, as well
as sign operations, add CRYPTO_TYPE_HEADER and CRYPTO_TYPE_PADDING
to the list of iovecs which will be hashed.
Creating and destroying an EVP_CTX_MD structure with every hash
operation is very expensive. Speed things up by caching one within
the krb5_crypto structure. krb5_crypto can already only be safely
used by one thread at a time - adding a message digest context here
shouldn't introduce any further threading risks.
Users of the stashed context must be careful to ensure that they
call no other hash functions whilst they are in the middle of using
the context.
Instead of flattening the iovecs passed into
krb5_verify_checksum_iov, create a new internal verify_checksum_iov
function which passes iovecs down onto the individual ->verify or
->checksum functions.
_krb5_find_enctype is a moderately expensive operation, as it
does a linear search of the enctype lists. Avoid calling it
in _key_schedule when we already have a key schedule in place.
This change makes the most common check the first in the function.
Rather than flattening the iovecs supplied to
krb5_create_checksum_iov into a malloc()'d memory block, refactor
the function so that they can be passed straight through to the
backend hash functions.
Modify the signature of the checksum operation in the
krb5_checksum_type structure so that it processes iovecs rather than
solid blocks of data.
Update all of the implementations of these functions for all of the
checksum types that we support so that they process iovecs, either
by iterating through the iovec in each function, or by calling
_krb5_evp_digest_iov or _krb5_evp_hmac_iov()
Update callers of these functions so that they turn their single blocks
of data into a single iovec of the correct type before calling checksum
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
(cherry picked from Samba commit 05cc099499ef3a07d140981ef82937c842a3ffef)
It is necessary to use the RFC3961 random_to_key operation when
creating a key from a bitstring.
Signed-off-by: Nicolas Williams <nico@cryptonector.com>
This reverts commit c25af51232 because
otherwise we could attempt to check a CKSUMTYPE_HMAC_SHA1_96_AES_256 key with a
KRB5_ENCTYPE_ARCFOUR_HMAC_MD5 key.
Andrew Bartlett
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
1. on errors, it appears to core dump, and
2. the sense of the return code is inverted from the
MIT implementation.
Signed-off-by: Love Hörnquist Åstrand <lha@h5l.org>
