The main fixes are
* the generation of fingerprints for RSA, ECDSA, and EdDSA
* the encoding of ECDSA private keys
* calculating p and q for RSA private keys
* deriving the public key for raw Ed25519 private keys
Also, instead of numeric literals for buffer lengths ASN.1 related
constants are used.
Instead, create a socket when necessary. Apparently, it can prevent
the agent from getting terminated (e.g. during system shutdown) if e.g.
charon-nm is still running with an open connection to the agent.
The functional reference created by ENGINE_init() was never released,
only the structural one created by ENGINE_by_id(). The functional
reference includes an implicit structural reference, which is also
released by ENGINE_finish().
Closesstrongswan/strongswan#119.
Same issue with signature malleability as with Ed25519 and apparently
OpenSSL doesn't even explicitly verify that the most significant 10 bits
are all zero.
As per RFC 8032, section 5.1.7 (and section 8.4) we have to make sure s, which
is the scalar in the second half of the signature value, is smaller than L.
Without that check, L can be added to most signatures at least once to create
another valid signature for the same public key and message.
This could be problematic if, for instance, a blacklist is based on hashes
of certificates. A new certificate could be created with a different
signature (without knowing the signature key) by simply adding L to s.
Currently, both OpenSSL 1.1.1 and Botan 2.8.0 are vulnerable to this, which is
why the unit test currently only warns about it.
OpenSSL 1.1.1 introduces DRGBs and provides two sources (same security
profile etc. but separate internal state), which allows us to use one for
RNG_WEAK (e.g. for nonces that are directly publicly visible) and the other
for stronger random data like keys.
While X25519 was already added with 1.1.0a, its use would be a lot more
complicated, as the helpers like EVP_PKEY_new_raw_public_key() were only
added in 1.1.1, which also added X448.
Because the file is not available on all platforms the inclusion comes
after the user options in order to disable including it. But that means
the inclusion also follows after the defined scanner states, which are
generated as simple #defines to numbers. If the included unistd.h e.g.
uses variables in function definitions with the same names this could
result in compilation errors.
Interactive mode has to be disabled too as it relies on isatty() from
unistd.h. Since we don't use the scanners interactively, this is not a
problem and might even make the scanners a bit faster.
Fixes#2806.
According to gcrypt.h these callbacks are not used anymore since
version 1.6 and with clang these actually cause deprecation warnings
that let the build on travis (-Werror) fail.
Checking for whitelisted functions in every backtrace is not very
efficient. And because OpenSSL 1.1 does no proper cleanup anymore until
the process is terminated there are now a lot more "leaks" to ignore.
For instance, in the openssl-ikev2/rw-cert scenario, just starting and
stopping the daemon (test vectors are checked) now causes 3594 whitelisted
leaks compared to the 849 before. This prolonged the shutdown of the
daemon on each guest in every scenario, amounting to multiple seconds of
additional runtime for every affected scenario. But even with this
patch there is still some overhead, compared to running the scenarios on
jessie.
SHA-384 is not supported but is selected by signature_schemes_for_key()
for keys between 3072 and 7680 bits.
Since this is only called for IKEv2 signature authentication we don't
even provide SHA-1 anymore. We always provide both schemes, though,
which is what pubkey-authenticator does too for RSA.
Older agents apparently just ignore the flags and always return a SHA-1
signature. If that's the case, charon.signature_authentication has to
be disabled.
Because `keylen` is unsigned the subtraction results in an integer
underflow if the key length is < 11 bytes.
This is only a problem when verifying signatures with a public key (for
private keys the plugin enforces a minimum modulus length) and to do so
we usually only use trusted keys. However, the x509 plugin actually
calls issued_by() on a parsed certificate to check if it is self-signed,
which is the reason this issue was found by OSS-Fuzz in the first place.
So, unfortunately, this can be triggered by sending an invalid client
cert to a peer.
Fixes: 5955db5b12 ("gmp: Don't parse PKCS1 v1.5 RSA signatures to verify them")
Fixes: CVE-2018-17540
Instead we generate the expected signature encoding and compare it to the
decrypted value.
Due to the lenient nature of the previous parsing code (minimum padding
length was not enforced, the algorithmIdentifier/OID parser accepts arbitrary
data after OIDs and in the parameters field etc.) it was susceptible to
Daniel Bleichenbacher's low-exponent attack (from 2006!), which allowed
forging signatures for keys that use low public exponents (i.e. e=3).
Since the public exponent is usually set to 0x10001 (65537) since quite a
while, the flaws in the previous code should not have had that much of a
practical impact in recent years.
Fixes: CVE-2018-16151, CVE-2018-16152
Tobias Brunner