Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
(cherry picked from Samba commit a0c8c8c8331856d9f09d18b389b7dd01c8d33de2)
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
(cherry picked from Samba commit b342e6f038b5277cf30115f11cf0f30d238c12ea)
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
(cherry picked from Samba commit 0358d57db4705b2330e294b5d6318c1a78a8518c)
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
(cherry picked from Samba commit 82c84513331da9d0f42ba73d03e58dce5d0f76d3)
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
(cherry picked from Samba commit b2b0f8191dde58fe234b0147c4a0bd39020aa504)
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
(cherry picked from Samba commit d20e85d008e1b7badbea5ada8b22639f7767a097)
Signed-off-by: Noel Power <noel.power@suse.com>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>
(cherry picked from Samba commit c6884138e4c1aec80e8f99ef0978b43919ae9d3a)
Without this, in an AS-REQ that has no local key for FAST
we would send the AS-REQ again, which can bump the bad
password count on the KDC twice.
So only try again if FAST was actually tried.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
In VC15 GetVersionEx has been deprecated. In order to continue to
support Win2K use the undeprecated VerifyVersionInfoW API
(available since Win2K).
Inline helper functions used in latest Win10 SDK to simplify code.
Zero out the DES_cblock structure instead of the (not yet used at this point
in the function) key schedule. The contents could potentially be left
on the stack in the case of an error return from _gssapi_verify_pad().
We generally clear out the cryptographic key and key schedule from
local variables before relinquishing control flow, but this case was
missed. Reported by jhb@FreeBSD.org.
GetSystemTimeAsFileTime() has 16ms precision.
GetSystemTimePreciseAsFileTime() has <1ns precision but is only available
on Windows 8 or later.
This change dynamically loads GetSystemTimePreciseAsFileTime() if it is
available.
Change-Id: Ib9c616c01948384e6b256ac9b6023f1e39673613
The iovec encryption code doesn't handle 0 length iovecs correctly.
Instead of just skipping them, _krb5_evp_encrypt_iov_cts() will spin
on the 0 length iovec.
Modify the _krb5_evp_iov_cursor_expand helper so that iovec expansion
simply skips 0 length iovecs, and make _krb5_evp_iov_cursor_nextcrypt
do the same.
Original bug report and tests from Andrew Bartlett <abartlet@samba.org>
../lib/com_err/compile_et.c: In function ‘generate_h’:
../lib/com_err/compile_et.c:138:33: error: ‘%s’ directive output may be truncated writing up to 127 bytes into a region of size 126 [-Werror=format-truncation=]
snprintf(fn, sizeof(fn), "__%s__", hfn);
^~ ~~~
../lib/com_err/compile_et.c:138:5: note: ‘snprintf’ output between 5 and 132 bytes into a destination of size 128
snprintf(fn, sizeof(fn), "__%s__", hfn);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../lib/com_err/compile_et.c: In function ‘main’:
../lib/com_err/compile_et.c:234:35: error: ‘.h’ directive output may be truncated writing 2 bytes into a region of size between 1 and 128 [-Werror=format-truncation=]
snprintf(hfn, sizeof(hfn), "%s.h", Basename);
^~
../lib/com_err/compile_et.c:234:5: note: ‘snprintf’ output between 3 and 130 bytes into a destination of size 128
snprintf(hfn, sizeof(hfn), "%s.h", Basename);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../lib/com_err/compile_et.c:235:35: error: ‘.c’ directive output may be truncated writing 2 bytes into a region of size between 1 and 128 [-Werror=format-truncation=]
snprintf(cfn, sizeof(cfn), "%s.c", Basename);
^~
../lib/com_err/compile_et.c:235:5: note: ‘snprintf’ output between 3 and 130 bytes into a destination of size 128
snprintf(cfn, sizeof(cfn), "%s.c", Basename);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
BUG: https://bugzilla.samba.org/show_bug.cgi?id=13437
Guenther
Signed-off-by: Günther Deschner <gd@samba.org>
Reviewed-by: Andreas Schneider <asn@samba.org>
Autobuild-User(master): Andreas Schneider <asn@cryptomilk.org>
Autobuild-Date(master): Fri Jun 8 13:23:51 CEST 2018 on sn-devel-144
(cherry picked from Samba commit 7ddbf6035dfec6806536f99d0257245f70661363)
The struct krb5_context_data field can be passed to plugins
which might not be aware of the new structure layout. To
reduce the risk of data corruption, fields must never be
removed, modified or reordered. Old unused fields are marked
deprecated and new fields are appended to the end of the structure.
This change moves two fields that were added to master which
are not present in Heimdal 7.x:
fe43be8558 added config_include_depth.
5b39bd7c1d added no_ticket_store.
Change-Id: I28b157e128732324972c99b246a93a828bc077c1
Some versions of gcc can't follow the logic in the encryption path
of the _krb5_evp_encrypt_iov_cts code, and believe that it is
possible for the lastpos structure to be used uninitialised.
This isn't actually possible. On entry to the loop, remaining is
guaranteed to be both greater than, and a multiple of blocksize.
In order to exit the loop, remaining must be set to 0. If
cursor.current.length >= remaining, then we set remaining to 0 and
also set lastpos. Otherwise, we calculate the number of whole blocks
in the current iovec, which must be less than remaining, and subtract
that from remaining. Remaining must still be a multiple of and greater
than or equal to blocksize. If remaining == blocksize, we set lastpos,
and set remaining to 0. Otherwise we consume a single block, and go
around again. All of the paths which may set remaining to 0 also
set lastpos, so lastpos must be populated when the loop terminates.
Coverity has a similiar misconception, albeit with ivec2, which is
mistaken for the same reasons.
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 iovec routines for both padded CBC, and CTS EVP based encryption.
These routines go to great lengths to minimise the number of times
we call EVP_Cipher. With some EVP implementations (such as OpenSSL's
AES-NI) there is a significant entrance and exit overhead from this
routine, due to the use of SIMD vectors for the ivec.
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.
