391 lines
18 KiB
ReStructuredText
391 lines
18 KiB
ReStructuredText
|
|
.. highlight:: none
|
|
|
|
Security Advisories
|
|
========================================
|
|
|
|
If you think you have found a security bug in Botan please contact
|
|
Jack Lloyd (jack@randombit.net). If you would like to encrypt your
|
|
mail please use::
|
|
|
|
pub rsa3072/57123B60 2015-03-23
|
|
Key fingerprint = 4E60 C735 51AF 2188 DF0A 5A62 78E9 8043 5712 3B60
|
|
uid Jack Lloyd <jack@randombit.net>
|
|
|
|
This key can be found in the file ``doc/pgpkey.txt`` or online at
|
|
https://keybase.io/jacklloyd and on most PGP keyservers.
|
|
|
|
2022
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* 2022-11-16: Failure to correctly check OCSP responder embedded certificate
|
|
|
|
OCSP responses for some end entity are either signed by the issuing CA certificate of
|
|
the PKI, or an OCSP responder certificate that the PKI authorized to sign responses in
|
|
their name. In the latter case, the responder certificate (and its validation path
|
|
certificate) may be embedded into the OCSP response and clients must verify that such
|
|
certificates are indeed authorized by the CA when validating OCSP responses.
|
|
|
|
The OCSP implementation failed to verify that an authorized responder certificate
|
|
embedded in an OCSP response is authorized by the issuing CA. As a result, any valid
|
|
signature by an embedded certificate passed the check and was allowed to make claims
|
|
about the revocation status of certificates of any CA.
|
|
|
|
Attackers that are in a position to spoof OCSP responses for a client could therefore
|
|
render legitimate certificates of a 3rd party CA as revoked or even use a compromised
|
|
(and actually revoked) certificate by spoofing an OCSP-"OK" response. E.g. an attacker
|
|
could exploit this to impersonate a legitimate TLS server using a compromised
|
|
certificate of that host and get around the revocation check using OCSP stapling.
|
|
|
|
Introduced in 1.11.34, fixed in 2.19.3
|
|
|
|
2020
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* 2020-12-21 (CVE-2021-24115): Codec encoding/decoding was not constant time
|
|
|
|
The base64, base32, base58 and hex encoding/decoding routines used lookup
|
|
tables which could leak information via a cache-based side channel attack.
|
|
The encoding tables were small and unlikely to be exploitable, but the
|
|
decoding tables were large enough to cause non-negligible information
|
|
leakage. In particular parsing an unencrypted PEM-encoded private key within
|
|
an SGX enclave could be easily attacked to leak key material.
|
|
|
|
Identified and reported by Jan Wichelmann, Thomas Eisenbarth,
|
|
Sebastian Berndt, and Florian Sieck.
|
|
|
|
Fixed in 2.17.3
|
|
|
|
* 2020-07-05: Failure to enforce name constraints on alternative names
|
|
|
|
The path validation algorithm enforced name constraints on the primary DN
|
|
included in the certificate but failed to do so against alternative DNs which
|
|
may be included in the subject alternative name. This would allow a corrupted
|
|
sub-CA which was constrained by a name constraints extension in its own
|
|
certificate to issue a certificate containing a prohibited DN. Until 2.15.0,
|
|
there was no API to access these alternative name DNs so it is unlikely that
|
|
any application would make incorrect access control decisions on the basis of
|
|
the incorrect DN. Reported by Mario Korth of Ruhr-Universität Bochum.
|
|
|
|
Introduced in 1.11.29, fixed in 2.15.0
|
|
|
|
* 2020-03-24: Side channel during CBC padding
|
|
|
|
The CBC padding operations were not constant time and as a result would leak
|
|
the length of the plaintext values which were being padded to an attacker
|
|
running a side channel attack via shared resources such as cache or branch
|
|
predictor. No information about the contents was leaked, but the length alone
|
|
might be used to make inferences about the contents. This issue affects TLS
|
|
CBC ciphersuites as well as CBC encryption using PKCS7 or other similar padding
|
|
mechanisms. In all cases, the unpadding operations were already constant time
|
|
and are not affected. Reported by Maximilian Blochberger of Universität
|
|
Hamburg.
|
|
|
|
Fixed in 2.14.0, all prior versions affected.
|
|
|
|
2018
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* 2018-12-17 (CVE-2018-20187): Side channel during ECC key generation
|
|
|
|
A timing side channel during ECC key generation could leak information about
|
|
the high bits of the secret scalar. Such information allows an attacker to
|
|
perform a brute force attack on the key somewhat more efficiently than they
|
|
would otherwise. Found by Ján Jančár using ECTester.
|
|
|
|
Introduced in 1.11.20, fixed in 2.8.0.
|
|
|
|
* 2018-06-13 (CVE-2018-12435): ECDSA side channel
|
|
|
|
A side channel in the ECDSA signature operation could allow a local attacker
|
|
to recover the secret key. Found by Keegan Ryan of NCC Group.
|
|
|
|
Bug introduced in 2.5.0, fixed in 2.7.0. The 1.10 branch is not affected.
|
|
|
|
* 2018-04-10 (CVE-2018-9860): Memory overread in TLS CBC decryption
|
|
|
|
An off by one error in TLS CBC decryption meant that for a particular
|
|
malformed ciphertext, the receiver would miscompute a length field and HMAC
|
|
exactly 64K bytes of data following the record buffer as if it was part of the
|
|
message. This cannot be used to leak information since the MAC comparison will
|
|
subsequently fail and the connection will be closed. However it might be used
|
|
for denial of service. Found by OSS-Fuzz.
|
|
|
|
Bug introduced in 1.11.32, fixed in 2.6.0
|
|
|
|
* 2018-03-29 (CVE-2018-9127): Invalid wildcard match
|
|
|
|
RFC 6125 wildcard matching was incorrectly implemented, so that a wildcard
|
|
certificate such as ``b*.domain.com`` would match any hosts ``*b*.domain.com``
|
|
instead of just server names beginning with ``b``. The host and certificate
|
|
would still have to be in the same domain name. Reported by Fabian Weißberg of
|
|
Rohde and Schwarz Cybersecurity.
|
|
|
|
Bug introduced in 2.2.0, fixed in 2.5.0
|
|
|
|
2017
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* 2017-10-02 (CVE-2017-14737): Potential side channel using cache information
|
|
|
|
In the Montgomery exponentiation code, a table of precomputed values
|
|
is used. An attacker able to analyze which cache lines were accessed
|
|
(perhaps via an active attack such as Prime+Probe) could recover
|
|
information about the exponent. Identified in "CacheD: Identifying
|
|
Cache-Based Timing Channels in Production Software" by Wang, Wang,
|
|
Liu, Zhang, and Wu (Usenix Security 2017).
|
|
|
|
Fixed in 1.10.17 and 2.3.0, all prior versions affected.
|
|
|
|
* 2017-07-16: Failure to fully zeroize memory before free
|
|
|
|
The secure_allocator type attempts to zeroize memory before freeing it. Due to
|
|
a error sometimes only a portion of the memory would be zeroed, because of a
|
|
confusion between the number of elements vs the number of bytes that those
|
|
elements use. So byte vectors would always be fully zeroed (since the two
|
|
notions result in the same value), but for example with an array of 32-bit
|
|
integers, only the first 1/4 of the elements would be zeroed before being
|
|
deallocated. This may result in information leakage, if an attacker can access
|
|
memory on the heap. Reported by Roman Pozlevich.
|
|
|
|
Bug introduced in 1.11.10, fixed in 2.2.0
|
|
|
|
* 2017-04-04 (CVE-2017-2801): Incorrect comparison in X.509 DN strings
|
|
|
|
Botan's implementation of X.509 name comparisons had a flaw which
|
|
could result in an out of bound memory read while processing a
|
|
specially formed DN. This could potentially be exploited for
|
|
information disclosure or denial of service, or result in incorrect
|
|
validation results. Found independently by Aleksandar Nikolic of
|
|
Cisco Talos, and OSS-Fuzz automated fuzzing infrastructure.
|
|
|
|
Bug introduced in 1.6.0 or earlier, fixed in 2.1.0 and 1.10.16
|
|
|
|
* 2017-03-23 (CVE-2017-7252): Incorrect bcrypt computation
|
|
|
|
Botan's implementation of bcrypt password hashing scheme truncated long
|
|
passwords at 56 characters, instead of at bcrypt's standard 72 characters
|
|
limit. Passwords with lengths between these two bounds could be cracked more
|
|
easily than should be the case due to the final password bytes being ignored.
|
|
Found and reported by Solar Designer.
|
|
|
|
Bug introduced in 1.11.0, fixed in 2.1.0.
|
|
|
|
2016
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* 2016-11-27 (CVE-2016-9132) Integer overflow in BER decoder
|
|
|
|
While decoding BER length fields, an integer overflow could occur. This could
|
|
occur while parsing untrusted inputs such as X.509 certificates. The overflow
|
|
does not seem to lead to any obviously exploitable condition, but exploitation
|
|
cannot be positively ruled out. Only 32-bit platforms are likely affected; to
|
|
cause an overflow on 64-bit the parsed data would have to be many gigabytes.
|
|
Bug found by Falko Strenzke, cryptosource GmbH.
|
|
|
|
Fixed in 1.10.14 and 1.11.34, all prior versions affected.
|
|
|
|
* 2016-10-26 (CVE-2016-8871) OAEP side channel
|
|
|
|
A side channel in OAEP decoding could be used to distinguish RSA ciphertexts
|
|
that did or did not have a leading 0 byte. For an attacker capable of
|
|
precisely measuring the time taken for OAEP decoding, this could be used as an
|
|
oracle allowing decryption of arbitrary RSA ciphertexts. Remote exploitation
|
|
seems difficult as OAEP decoding is always paired with RSA decryption, which
|
|
takes substantially more (and variable) time, and so will tend to mask the
|
|
timing channel. This attack does seems well within reach of a local attacker
|
|
capable of a cache or branch predictor based side channel attack. Finding,
|
|
analysis, and patch by Juraj Somorovsky.
|
|
|
|
Introduced in 1.11.29, fixed in 1.11.33
|
|
|
|
* 2016-08-30 (CVE-2016-6878) Undefined behavior in Curve25519
|
|
|
|
On systems without a native 128-bit integer type, the Curve25519 code invoked
|
|
undefined behavior. This was known to produce incorrect results on 32-bit ARM
|
|
when compiled by Clang.
|
|
|
|
Introduced in 1.11.12, fixed in 1.11.31
|
|
|
|
* 2016-08-30 (CVE-2016-6879) Bad result from X509_Certificate::allowed_usage
|
|
|
|
If allowed_usage was called with more than one Key_Usage set in the enum
|
|
value, the function would return true if *any* of the allowed usages were set,
|
|
instead of if *all* of the allowed usages are set. This could be used to
|
|
bypass an application key usage check. Credit to Daniel Neus of Rohde &
|
|
Schwarz Cybersecurity for finding this issue.
|
|
|
|
Introduced in 1.11.0, fixed in 1.11.31
|
|
|
|
* 2016-03-17 (CVE-2016-2849): ECDSA side channel
|
|
|
|
ECDSA (and DSA) signature algorithms perform a modular inverse on the
|
|
signature nonce `k`. The modular inverse algorithm used had input dependent
|
|
loops, and it is possible a side channel attack could recover sufficient
|
|
information about the nonce to eventually recover the ECDSA secret key. Found
|
|
by Sean Devlin.
|
|
|
|
Introduced in 1.7.15, fixed in 1.10.13 and 1.11.29
|
|
|
|
* 2016-03-17 (CVE-2016-2850): Failure to enforce TLS policy
|
|
|
|
TLS v1.2 allows negotiating which signature algorithms and hash functions each
|
|
side is willing to accept. However received signatures were not actually
|
|
checked against the specified policy. This had the effect of allowing a
|
|
server to use an MD5 or SHA-1 signature, even though the default policy
|
|
prohibits it. The same issue affected client cert authentication.
|
|
|
|
The TLS client also failed to verify that the ECC curve the server chose to
|
|
use was one which was acceptable by the client policy.
|
|
|
|
Introduced in 1.11.0, fixed in 1.11.29
|
|
|
|
* 2016-02-01 (CVE-2016-2196): Overwrite in P-521 reduction
|
|
|
|
The P-521 reduction function would overwrite zero to one word
|
|
following the allocated block. This could potentially result
|
|
in remote code execution or a crash. Found with AFL
|
|
|
|
Introduced in 1.11.10, fixed in 1.11.27
|
|
|
|
* 2016-02-01 (CVE-2016-2195): Heap overflow on invalid ECC point
|
|
|
|
The PointGFp constructor did not check that the affine coordinate
|
|
arguments were less than the prime, but then in curve multiplication
|
|
assumed that both arguments if multiplied would fit into an integer
|
|
twice the size of the prime.
|
|
|
|
The bigint_mul and bigint_sqr functions received the size of the
|
|
output buffer, but only used it to dispatch to a faster algorithm in
|
|
cases where there was sufficient output space to call an unrolled
|
|
multiplication function.
|
|
|
|
The result is a heap overflow accessible via ECC point decoding,
|
|
which accepted untrusted inputs. This is likely exploitable for
|
|
remote code execution.
|
|
|
|
On systems which use the mlock pool allocator, it would allow an
|
|
attacker to overwrite memory held in secure_vector objects. After
|
|
this point the write will hit the guard page at the end of the
|
|
mmap'ed region so it probably could not be used for code execution
|
|
directly, but would allow overwriting adjacent key material.
|
|
|
|
Found by Alex Gaynor fuzzing with AFL
|
|
|
|
Introduced in 1.9.18, fixed in 1.11.27 and 1.10.11
|
|
|
|
* 2016-02-01 (CVE-2016-2194): Infinite loop in modular square root algorithm
|
|
|
|
The ressol function implements the Tonelli-Shanks algorithm for
|
|
finding square roots could be sent into a nearly infinite loop due
|
|
to a misplaced conditional check. This could occur if a composite
|
|
modulus is provided, as this algorithm is only defined for primes.
|
|
This function is exposed to attacker controlled input via the OS2ECP
|
|
function during ECC point decompression. Found by AFL
|
|
|
|
Introduced in 1.7.15, fixed in 1.11.27 and 1.10.11
|
|
|
|
2015
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* 2015-11-04: TLS certificate authentication bypass
|
|
|
|
When the bugs affecting X.509 path validation were fixed in 1.11.22, a check
|
|
in Credentials_Manager::verify_certificate_chain was accidentally removed
|
|
which caused path validation failures not to be signaled to the TLS layer. So
|
|
for affected versions, certificate authentication in TLS is bypassed. As a
|
|
workaround, applications can override the call and implement the correct
|
|
check. Reported by Florent Le Coz in GH #324
|
|
|
|
Introduced in 1.11.22, fixed in 1.11.24
|
|
|
|
* 2015-10-26 (CVE-2015-7824): Padding oracle attack on TLS
|
|
|
|
A padding oracle attack was possible against TLS CBC ciphersuites because if a
|
|
certain length check on the packet fields failed, a different alert type than
|
|
one used for message authentication failure would be returned to the sender.
|
|
This check triggering would leak information about the value of the padding
|
|
bytes and could be used to perform iterative decryption.
|
|
|
|
As with most such oracle attacks, the danger depends on the underlying
|
|
protocol - HTTP servers are particularly vulnerable. The current analysis
|
|
suggests that to exploit it an attacker would first have to guess several
|
|
bytes of plaintext, but again this is quite possible in many situations
|
|
including HTTP.
|
|
|
|
Found in a review by Sirrix AG and 3curity GmbH.
|
|
|
|
Introduced in 1.11.0, fixed in 1.11.22
|
|
|
|
* 2015-10-26 (CVE-2015-7825): Infinite loop during certificate path validation
|
|
|
|
When evaluating a certificate path, if a loop in the certificate chain
|
|
was encountered (for instance where C1 certifies C2, which certifies C1)
|
|
an infinite loop would occur eventually resulting in memory exhaustion.
|
|
Found in a review by Sirrix AG and 3curity GmbH.
|
|
|
|
Introduced in 1.11.6, fixed in 1.11.22
|
|
|
|
* 2015-10-26 (CVE-2015-7826): Acceptance of invalid certificate names
|
|
|
|
RFC 6125 specifies how to match a X.509v3 certificate against a DNS name
|
|
for application usage.
|
|
|
|
Otherwise valid certificates using wildcards would be accepted as matching
|
|
certain hostnames that should they should not according to RFC 6125. For
|
|
example a certificate issued for ``*.example.com`` should match
|
|
``foo.example.com`` but not ``example.com`` or ``bar.foo.example.com``. Previously
|
|
Botan would accept such a certificate as also valid for ``bar.foo.example.com``.
|
|
|
|
RFC 6125 also requires that when matching a X.509 certificate against a DNS
|
|
name, the CN entry is only compared if no subjectAlternativeName entry is
|
|
available. Previously X509_Certificate::matches_dns_name would always check
|
|
both names.
|
|
|
|
Found in a review by Sirrix AG and 3curity GmbH.
|
|
|
|
Introduced in 1.11.0, fixed in 1.11.22
|
|
|
|
* 2015-10-26 (CVE-2015-7827): PKCS #1 v1.5 decoding was not constant time
|
|
|
|
During RSA decryption, how long decoding of PKCS #1 v1.5 padding took was
|
|
input dependent. If these differences could be measured by an attacker, it
|
|
could be used to mount a Bleichenbacher million-message attack. PKCS #1 v1.5
|
|
decoding has been rewritten to use a sequence of operations which do not
|
|
contain any input-dependent indexes or jumps. Notations for checking constant
|
|
time blocks with ctgrind (https://github.com/agl/ctgrind) were added to PKCS
|
|
#1 decoding among other areas. Found in a review by Sirrix AG and 3curity GmbH.
|
|
|
|
Fixed in 1.11.22 and 1.10.13. Affected all previous versions.
|
|
|
|
* 2015-08-03 (CVE-2015-5726): Crash in BER decoder
|
|
|
|
The BER decoder would crash due to reading from offset 0 of an empty vector if
|
|
it encountered a BIT STRING which did not contain any data at all. This can be
|
|
used to easily crash applications reading untrusted ASN.1 data, but does not
|
|
seem exploitable for code execution. Found with afl.
|
|
|
|
Fixed in 1.11.19 and 1.10.10, affected all previous versions of 1.10 and 1.11
|
|
|
|
* 2015-08-03 (CVE-2015-5727): Excess memory allocation in BER decoder
|
|
|
|
The BER decoder would allocate a fairly arbitrary amount of memory in a length
|
|
field, even if there was no chance the read request would succeed. This might
|
|
cause the process to run out of memory or invoke the OOM killer. Found with afl.
|
|
|
|
Fixed in 1.11.19 and 1.10.10, affected all previous versions of 1.10 and 1.11
|
|
|
|
2014
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
* 2014-04-10 (CVE-2014-9742): Insufficient randomness in Miller-Rabin primality check
|
|
|
|
A bug in the Miller-Rabin primality test resulted in only a single random base
|
|
being used instead of a sequence of such bases. This increased the probability
|
|
that a non-prime would be accepted by is_prime or that a randomly generated
|
|
prime might actually be composite. The probability of a random 1024 bit
|
|
number being incorrectly classed as prime with a single base is around 2^-40.
|
|
Reported by Jeff Marrison.
|
|
|
|
Introduced in 1.8.3, fixed in 1.10.8 and 1.11.9
|