1 2.. highlight:: none 3 4Security Advisories 5======================================== 6 7If you think you have found a security bug in Botan please contact 8Jack Lloyd (jack@randombit.net). If you would like to encrypt your 9mail please use:: 10 11 pub rsa3072/57123B60 2015-03-23 12 Key fingerprint = 4E60 C735 51AF 2188 DF0A 5A62 78E9 8043 5712 3B60 13 uid Jack Lloyd <jack@randombit.net> 14 15This key can be found in the file ``doc/pgpkey.txt`` or online at 16https://keybase.io/jacklloyd and on most PGP keyservers. 17 182020 19^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 20 21* 2020-07-05: Failure to enforce name constraints on alternative names 22 23 The path validation algorithm enforced name constraints on the primary DN 24 included in the certificate but failed to do so against alternative DNs which 25 may be included in the subject alternative name. This would allow a corrupted 26 sub-CA which was constrained by a name constraints extension in its own 27 certificate to issue a certificate containing a prohibited DN. Until 2.15.0, 28 there was no API to access these alternative name DNs so it is unlikely that 29 any application would make incorrect access control decisions on the basis of 30 the incorrect DN. Reported by Mario Korth of Ruhr-Universität Bochum. 31 32 Introduced in 1.11.29, fixed in 2.15.0 33 34* 2020-03-24: Side channel during CBC padding 35 36 The CBC padding operations were not constant time and as a result would leak 37 the length of the plaintext values which were being padded to an attacker 38 running a side channel attack via shared resources such as cache or branch 39 predictor. No information about the contents was leaked, but the length alone 40 might be used to make inferences about the contents. This issue affects TLS 41 CBC ciphersuites as well as CBC encryption using PKCS7 or other similar padding 42 mechanisms. In all cases, the unpadding operations were already constant time 43 and are not affected. Reported by Maximilian Blochberger of Universität 44 Hamburg. 45 46 Fixed in 2.14.0, all prior versions affected. 47 482018 49^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 50 51* 2018-12-17 (CVE-2018-20187): Side channel during ECC key generation 52 53 A timing side channel during ECC key generation could leak information about 54 the high bits of the secret scalar. Such information allows an attacker to 55 perform a brute force attack on the key somewhat more efficiently than they 56 would otherwise. Found by Ján Jančár using ECTester. 57 58 Introduced in 1.11.20, fixed in 2.8.0. 59 60* 2018-06-13 (CVE-2018-12435): ECDSA side channel 61 62 A side channel in the ECDSA signature operation could allow a local attacker 63 to recover the secret key. Found by Keegan Ryan of NCC Group. 64 65 Bug introduced in 2.5.0, fixed in 2.7.0. The 1.10 branch is not affected. 66 67* 2018-04-10 (CVE-2018-9860): Memory overread in TLS CBC decryption 68 69 An off by one error in TLS CBC decryption meant that for a particular 70 malformed ciphertext, the receiver would miscompute a length field and HMAC 71 exactly 64K bytes of data following the record buffer as if it was part of the 72 message. This cannot be used to leak information since the MAC comparison will 73 subsequently fail and the connection will be closed. However it might be used 74 for denial of service. Found by OSS-Fuzz. 75 76 Bug introduced in 1.11.32, fixed in 2.6.0 77 78* 2018-03-29 (CVE-2018-9127): Invalid wildcard match 79 80 RFC 6125 wildcard matching was incorrectly implemented, so that a wildcard 81 certificate such as ``b*.domain.com`` would match any hosts ``*b*.domain.com`` 82 instead of just server names beginning with ``b``. The host and certificate 83 would still have to be in the same domain name. Reported by Fabian Weißberg of 84 Rohde and Schwarz Cybersecurity. 85 86 Bug introduced in 2.2.0, fixed in 2.5.0 87 882017 89^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 90 91* 2017-10-02 (CVE-2017-14737): Potential side channel using cache information 92 93 In the Montgomery exponentiation code, a table of precomputed values 94 is used. An attacker able to analyze which cache lines were accessed 95 (perhaps via an active attack such as Prime+Probe) could recover 96 information about the exponent. Identified in "CacheD: Identifying 97 Cache-Based Timing Channels in Production Software" by Wang, Wang, 98 Liu, Zhang, and Wu (Usenix Security 2017). 99 100 Fixed in 1.10.17 and 2.3.0, all prior versions affected. 101 102* 2017-07-16: Failure to fully zeroize memory before free 103 104 The secure_allocator type attempts to zeroize memory before freeing it. Due to 105 a error sometimes only a portion of the memory would be zeroed, because of a 106 confusion between the number of elements vs the number of bytes that those 107 elements use. So byte vectors would always be fully zeroed (since the two 108 notions result in the same value), but for example with an array of 32-bit 109 integers, only the first 1/4 of the elements would be zeroed before being 110 deallocated. This may result in information leakage, if an attacker can access 111 memory on the heap. Reported by Roman Pozlevich. 112 113 Bug introduced in 1.11.10, fixed in 2.2.0 114 115* 2017-04-04 (CVE-2017-2801): Incorrect comparison in X.509 DN strings 116 117 Botan's implementation of X.509 name comparisons had a flaw which 118 could result in an out of bound memory read while processing a 119 specially formed DN. This could potentially be exploited for 120 information disclosure or denial of service, or result in incorrect 121 validation results. Found independently by Aleksandar Nikolic of 122 Cisco Talos, and OSS-Fuzz automated fuzzing infrastructure. 123 124 Bug introduced in 1.6.0 or earlier, fixed in 2.1.0 and 1.10.16 125 126* 2017-03-23 (CVE-2017-7252): Incorrect bcrypt computation 127 128 Botan's implementation of bcrypt password hashing scheme truncated long 129 passwords at 56 characters, instead of at bcrypt's standard 72 characters 130 limit. Passwords with lengths between these two bounds could be cracked more 131 easily than should be the case due to the final password bytes being ignored. 132 Found and reported by Solar Designer. 133 134 Bug introduced in 1.11.0, fixed in 2.1.0. 135 1362016 137^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 138 139* 2016-11-27 (CVE-2016-9132) Integer overflow in BER decoder 140 141 While decoding BER length fields, an integer overflow could occur. This could 142 occur while parsing untrusted inputs such as X.509 certificates. The overflow 143 does not seem to lead to any obviously exploitable condition, but exploitation 144 cannot be positively ruled out. Only 32-bit platforms are likely affected; to 145 cause an overflow on 64-bit the parsed data would have to be many gigabytes. 146 Bug found by Falko Strenzke, cryptosource GmbH. 147 148 Fixed in 1.10.14 and 1.11.34, all prior versions affected. 149 150* 2016-10-26 (CVE-2016-8871) OAEP side channel 151 152 A side channel in OAEP decoding could be used to distinguish RSA ciphertexts 153 that did or did not have a leading 0 byte. For an attacker capable of 154 precisely measuring the time taken for OAEP decoding, this could be used as an 155 oracle allowing decryption of arbitrary RSA ciphertexts. Remote exploitation 156 seems difficult as OAEP decoding is always paired with RSA decryption, which 157 takes substantially more (and variable) time, and so will tend to mask the 158 timing channel. This attack does seems well within reach of a local attacker 159 capable of a cache or branch predictor based side channel attack. Finding, 160 analysis, and patch by Juraj Somorovsky. 161 162 Introduced in 1.11.29, fixed in 1.11.33 163 164* 2016-08-30 (CVE-2016-6878) Undefined behavior in Curve25519 165 166 On systems without a native 128-bit integer type, the Curve25519 code invoked 167 undefined behavior. This was known to produce incorrect results on 32-bit ARM 168 when compiled by Clang. 169 170 Introduced in 1.11.12, fixed in 1.11.31 171 172* 2016-08-30 (CVE-2016-6879) Bad result from X509_Certificate::allowed_usage 173 174 If allowed_usage was called with more than one Key_Usage set in the enum 175 value, the function would return true if *any* of the allowed usages were set, 176 instead of if *all* of the allowed usages are set. This could be used to 177 bypass an application key usage check. Credit to Daniel Neus of Rohde & 178 Schwarz Cybersecurity for finding this issue. 179 180 Introduced in 1.11.0, fixed in 1.11.31 181 182* 2016-03-17 (CVE-2016-2849): ECDSA side channel 183 184 ECDSA (and DSA) signature algorithms perform a modular inverse on the 185 signature nonce `k`. The modular inverse algorithm used had input dependent 186 loops, and it is possible a side channel attack could recover sufficient 187 information about the nonce to eventually recover the ECDSA secret key. Found 188 by Sean Devlin. 189 190 Introduced in 1.7.15, fixed in 1.10.13 and 1.11.29 191 192* 2016-03-17 (CVE-2016-2850): Failure to enforce TLS policy 193 194 TLS v1.2 allows negotiating which signature algorithms and hash functions each 195 side is willing to accept. However received signatures were not actually 196 checked against the specified policy. This had the effect of allowing a 197 server to use an MD5 or SHA-1 signature, even though the default policy 198 prohibits it. The same issue affected client cert authentication. 199 200 The TLS client also failed to verify that the ECC curve the server chose to 201 use was one which was acceptable by the client policy. 202 203 Introduced in 1.11.0, fixed in 1.11.29 204 205* 2016-02-01 (CVE-2016-2196): Overwrite in P-521 reduction 206 207 The P-521 reduction function would overwrite zero to one word 208 following the allocated block. This could potentially result 209 in remote code execution or a crash. Found with AFL 210 211 Introduced in 1.11.10, fixed in 1.11.27 212 213* 2016-02-01 (CVE-2016-2195): Heap overflow on invalid ECC point 214 215 The PointGFp constructor did not check that the affine coordinate 216 arguments were less than the prime, but then in curve multiplication 217 assumed that both arguments if multiplied would fit into an integer 218 twice the size of the prime. 219 220 The bigint_mul and bigint_sqr functions received the size of the 221 output buffer, but only used it to dispatch to a faster algorithm in 222 cases where there was sufficient output space to call an unrolled 223 multiplication function. 224 225 The result is a heap overflow accessible via ECC point decoding, 226 which accepted untrusted inputs. This is likely exploitable for 227 remote code execution. 228 229 On systems which use the mlock pool allocator, it would allow an 230 attacker to overwrite memory held in secure_vector objects. After 231 this point the write will hit the guard page at the end of the 232 mmap'ed region so it probably could not be used for code execution 233 directly, but would allow overwriting adjacent key material. 234 235 Found by Alex Gaynor fuzzing with AFL 236 237 Introduced in 1.9.18, fixed in 1.11.27 and 1.10.11 238 239* 2016-02-01 (CVE-2016-2194): Infinite loop in modular square root algorithm 240 241 The ressol function implements the Tonelli-Shanks algorithm for 242 finding square roots could be sent into a nearly infinite loop due 243 to a misplaced conditional check. This could occur if a composite 244 modulus is provided, as this algorithm is only defined for primes. 245 This function is exposed to attacker controlled input via the OS2ECP 246 function during ECC point decompression. Found by AFL 247 248 Introduced in 1.7.15, fixed in 1.11.27 and 1.10.11 249 2502015 251^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 252 253* 2015-11-04: TLS certificate authentication bypass 254 255 When the bugs affecting X.509 path validation were fixed in 1.11.22, a check 256 in Credentials_Manager::verify_certificate_chain was accidentally removed 257 which caused path validation failures not to be signaled to the TLS layer. So 258 for affected versions, certificate authentication in TLS is bypassed. As a 259 workaround, applications can override the call and implement the correct 260 check. Reported by Florent Le Coz in GH #324 261 262 Introduced in 1.11.22, fixed in 1.11.24 263 264* 2015-10-26 (CVE-2015-7824): Padding oracle attack on TLS 265 266 A padding oracle attack was possible against TLS CBC ciphersuites because if a 267 certain length check on the packet fields failed, a different alert type than 268 one used for message authentication failure would be returned to the sender. 269 This check triggering would leak information about the value of the padding 270 bytes and could be used to perform iterative decryption. 271 272 As with most such oracle attacks, the danger depends on the underlying 273 protocol - HTTP servers are particularly vulnerable. The current analysis 274 suggests that to exploit it an attacker would first have to guess several 275 bytes of plaintext, but again this is quite possible in many situations 276 including HTTP. 277 278 Found in a review by Sirrix AG and 3curity GmbH. 279 280 Introduced in 1.11.0, fixed in 1.11.22 281 282* 2015-10-26 (CVE-2015-7825): Infinite loop during certificate path validation 283 284 When evaluating a certificate path, if a loop in the certificate chain 285 was encountered (for instance where C1 certifies C2, which certifies C1) 286 an infinite loop would occur eventually resulting in memory exhaustion. 287 Found in a review by Sirrix AG and 3curity GmbH. 288 289 Introduced in 1.11.6, fixed in 1.11.22 290 291* 2015-10-26 (CVE-2015-7826): Acceptance of invalid certificate names 292 293 RFC 6125 specifies how to match a X.509v3 certificate against a DNS name 294 for application usage. 295 296 Otherwise valid certificates using wildcards would be accepted as matching 297 certain hostnames that should they should not according to RFC 6125. For 298 example a certificate issued for ``*.example.com`` should match 299 ``foo.example.com`` but not ``example.com`` or ``bar.foo.example.com``. Previously 300 Botan would accept such a certificate as also valid for ``bar.foo.example.com``. 301 302 RFC 6125 also requires that when matching a X.509 certificate against a DNS 303 name, the CN entry is only compared if no subjectAlternativeName entry is 304 available. Previously X509_Certificate::matches_dns_name would always check 305 both names. 306 307 Found in a review by Sirrix AG and 3curity GmbH. 308 309 Introduced in 1.11.0, fixed in 1.11.22 310 311* 2015-10-26 (CVE-2015-7827): PKCS #1 v1.5 decoding was not constant time 312 313 During RSA decryption, how long decoding of PKCS #1 v1.5 padding took was 314 input dependent. If these differences could be measured by an attacker, it 315 could be used to mount a Bleichenbacher million-message attack. PKCS #1 v1.5 316 decoding has been rewritten to use a sequence of operations which do not 317 contain any input-dependent indexes or jumps. Notations for checking constant 318 time blocks with ctgrind (https://github.com/agl/ctgrind) were added to PKCS 319 #1 decoding among other areas. Found in a review by Sirrix AG and 3curity GmbH. 320 321 Fixed in 1.11.22 and 1.10.13. Affected all previous versions. 322 323* 2015-08-03 (CVE-2015-5726): Crash in BER decoder 324 325 The BER decoder would crash due to reading from offset 0 of an empty vector if 326 it encountered a BIT STRING which did not contain any data at all. This can be 327 used to easily crash applications reading untrusted ASN.1 data, but does not 328 seem exploitable for code execution. Found with afl. 329 330 Fixed in 1.11.19 and 1.10.10, affected all previous versions of 1.10 and 1.11 331 332* 2015-08-03 (CVE-2015-5727): Excess memory allocation in BER decoder 333 334 The BER decoder would allocate a fairly arbitrary amount of memory in a length 335 field, even if there was no chance the read request would succeed. This might 336 cause the process to run out of memory or invoke the OOM killer. Found with afl. 337 338 Fixed in 1.11.19 and 1.10.10, affected all previous versions of 1.10 and 1.11 339 3402014 341^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 342 343* 2014-04-10 (CVE-2014-9742): Insufficient randomness in Miller-Rabin primality check 344 345 A bug in the Miller-Rabin primality test resulted in only a single random base 346 being used instead of a sequence of such bases. This increased the probability 347 that a non-prime would be accepted by is_prime or that a randomly generated 348 prime might actually be composite. The probability of a random 1024 bit 349 number being incorrectly classed as prime with a single base is around 2^-40. 350 Reported by Jeff Marrison. 351 352 Introduced in 1.8.3, fixed in 1.10.8 and 1.11.9 353