Age | Commit message (Collapse) | Author |
|
We received analytics that devices of the device family Oppo A37x
are crashing with SIGILL when trying to load libcrypto.so.
These crashes were fixed by using the system-supplied getauxval function.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15763)
|
|
Fixes #9498
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15870)
|
|
The s390x cipher implementations must call their init function
even if the key argument is NULL to allow initializing the
cipher operation's context in any order.
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14900)
|
|
ASN1_STRING_length gets the field 'length' of msg, which
can be manipulated through a crafted input.
Add a check to avoid error execution of OPENSSL_malloc().
CLA: trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15583)
(cherry picked from commit effb0dcf864110a4595f1a243adb9c1dd09eb516)
|
|
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15315)
(cherry picked from commit 6d3f798cba8075e700003aaf34f1e72bb930086c)
|
|
X509_VERIFY_PARAM_inherit() now copies hostflags independently of hosts.
Previously hostflags were only copied when at least one host was set.
Typically applications don't configure hosts on SSL_CTX. The change
enables applications to configure hostflags on SSL_CTX and have OpenSSL
copy the flags from SSL_CTX to SSL.
Fixes: https://github.com/openssl/openssl/issues/14579
Signed-off-by: Christian Heimes <christian@python.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14856)
|
|
In hybrid and compressed point encodings, the form octet contains a bit
of information allowing to calculate y from x. For a point on a binary
curve, this bit is zero if x is zero, otherwise it must match the
rightmost bit of of the field element y / x. The existing code only
considers the second possibility. It could thus incorrecly fail with a
division by zero error as found by Guido Vranken's cryptofuzz.
This commit adds a few explanatory comments to oct2point. The only
actual code change is in the last hunk which adds a BN_is_zero(x)
check to avoid the division by zero.
Fixes #15021
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15112)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15255)
|
|
add a length check to the return value of function i2d_ASN1_TYPE. Return an error instead of trying to malloc a negative number.
CLA: trivial
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14828)
(cherry picked from commit c65abf2213117eb5348a46fbc18f706aca052e85)
|
|
Fixes #15022
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15075)
|
|
and true
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/15015)
(cherry picked from commit f7f0632b01cf16efccb133e395cf115c194bd003)
|
|
Fixes #12735 for 1.1.1
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/15109)
|
|
The 'sn' and 'ln' strings may be dynamically allocated, and the
ASN1_OBJECT flags have a bit set to say this. If an ASN1_OBJECT with
such strings is passed to d2i_ASN1_OBJECT() for reuse, the strings
must be freed, or there is a memory leak.
Fixes #14667
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/14938)
|
|
Fixes #14147
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14982)
|
|
In function try_decode_PKCS8Encrypted, p8 is freed via X509_SIG_free() at line 481.
If function new_EMBEDDED() returns a null pointer at line 483, the execution will goto nop8.
In the nop8 branch, p8 is freed again at line 491.
Bug reported by @Yunlongs
Fixes #14915
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14921)
(cherry picked from commit efe8d69daa1a68be0a7f0f73220947c848e7ed1d)
|
|
In function int_ts_RESP_verify_token, if (flags & TS_VFY_DATA) is true, function ts_compute_imprint() will be called at line 299.
In the implementation of ts_compute_imprint, it allocates md_alg at line 406.
But after the allocation, if the execution goto err, then md_alg will be freed in the first time by X509_ALGOR_free at line 439.
After that, ts_compute_imprint returns 0 and the execution goto err branch of int_ts_RESP_verify_token.
In the err branch, md_alg will be freed in the second time at line 320.
Bug reported by @Yunlongs
Fixes #14914
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14921)
(cherry picked from commit db78c84eb2fa9c41124690bcc2ea50e05f5fc7b7)
|
|
In function SRP_create_verifier_ex, it calls SRP_create_verifier_BN_ex(..., &v, ..) at line 653.
In the implementation of SRP_create_verifier_BN_ex(), *verify (which is the paremeter of v) is allocated a pointer via BN_new() at line 738.
And *verify is freed via BN_clear_free() at line 743, and return 0.
Then the execution continues up to goto err at line 655, and the freed v is freed again at line 687.
Bug reported by @Yunlongs
Fixes #14913
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14921)
(cherry picked from commit b06450bcf763735a89b65ca3ec176600fe7fceed)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
|
|
The X509_V_FLAG_X509_STRICT flag enables additional security checks of the
certificates present in a certificate chain. It is not set by default.
Starting from OpenSSL version 1.1.1h a check to disallow certificates with
explicitly encoded elliptic curve parameters in the chain was added to the
strict checks.
An error in the implementation of this check meant that the result of a
previous check to confirm that certificates in the chain are valid CA
certificates was overwritten. This effectively bypasses the check
that non-CA certificates must not be able to issue other certificates.
If a "purpose" has been configured then a subsequent check that the
certificate is consistent with that purpose also checks that it is a
valid CA. Therefore where a purpose is set the certificate chain will
still be rejected even when the strict flag has been used. A purpose is
set by default in libssl client and server certificate verification
routines, but it can be overriden by an application.
Affected applications explicitly set the X509_V_FLAG_X509_STRICT
verification flag and either do not set a purpose for the certificate
verification or, in the case of TLS client or server applications,
override the default purpose to make it not set.
CVE-2021-3450
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
|
|
When encountering a badly coded item, the DER printer (ASN1_print_dump())
sets a flag to ensure that an additional hex dump of the offending content
is printed as part of the output. Unfortunately, this flag is never reset,
which means that all following items are printed with the extra hex dump,
whether they are faulty or not.
Resetting the flag after hex dumping ensures that only the faulty contents
are printed with the additional hex dump.
Fixes #14626
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14627)
(cherry picked from commit 6e34a1048ce4871371eac224b995c3b4338f6166)
|
|
Some of the callbacks in rand_lib.c were being invoked without the
RUN_ONCE for that file being called. We add it during rand_pool_new
which should cover all cases.
Fixes #7870
Fixes #11144
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14603)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14584)
(cherry picked from commit b875e0e820b07420429ebb90724ed28686a98853)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14584)
(cherry picked from commit 145f12d12dc83c737676883c625c2a95d34251ed)
|
|
Return an error instead of trying to malloc a negative number.
The other usage in this file already had a similar check, and the caller
should have put an entry on the error stack already.
Note that we only check the initial calls to obtain the encoded length,
and assume that the follow-up call to actually encode to the allocated
storage will succeed if the first one did.
Fixes: #14177
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/14308)
(cherry picked from commit 90b4247cc5dca58cee9da5f6975bb38fd200100a)
|
|
If input offset_sec is sufficiently large (> INT32_MAX * SECS_PER_DAY, which is possible for a long on 64-bit platforms), then the first assignment contains an overflow.
I think leaving offset_hms as an int is still safe.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/14252)
(cherry picked from commit 75de54363506e2b2480fc6baf0cd45b1f7fc8816)
|
|
The incorrect code is in #ifdef branch that is normally
not compiled in.
Signed-off-by: Zhang Jinde <zjd5536@163.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12968)
(cherry picked from commit 1d724b5e82ba36fb50fd24db3cd664da570daf84)
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(cherry picked from commit 3ddf44ea5a2c1c8c55f4f4072a611791c79d4e7c)
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13853)
|
|
FreeBSD's current /dev/crypto implementation requires that consumers
clone a separate file descriptor via the CRIOGET ioctl that can then
be used with other ioctls such as CIOCGSESSION.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(cherry picked from commit b39c215decf6e68c28cb64dcfaf5ae5a7e8d35b4)
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13853)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
CVE-2021-23840
Reviewed-by: Paul Dale <pauli@openssl.org>
|
|
This also fixes the public function RSA_padding_check_SSLv23.
Commit 6555a89 changed the padding check logic in RSA_padding_check_SSLv23
so that padding is rejected if the nul delimiter byte is not immediately
preceded by at least 8 bytes containing 0x03. Prior to that commit the
padding is rejected if it *is* preceded by at least 8 bytes containing 0x03.
Presumably this change was made to be consistent with what it says in
appendix E.3 of RFC 5246. Unfortunately that RFC is in error, and the
original behaviour was correct. This is fixed in later errata issued for
that RFC.
This has no impact on libssl for modern versions of OpenSSL because
there is no protocol support for SSLv2 in these versions. However
applications that call RSA_paddin_check_SSLv23 directly, or use the
RSA_SSLV23_PADDING mode may still be impacted. The effect of the original
error is that an RSA message encrypted by an SSLv2 only client will fail to
be decrypted properly by a TLS capable server, or a message encrypted by a
TLS capable client will fail to decrypt on an SSLv2 only server. Most
significantly an RSA message encrypted by a TLS capable client will be
successfully decrypted by a TLS capable server. This last case should fail
due to a rollback being detected.
Thanks to D. Katz and Joel Luellwitz (both from Trustwave) for reporting
this issue.
CVE-2021-23839
Reviewed-by: Paul Dale <pauli@openssl.org>
|
|
The OpenSSL public API function X509_issuer_and_serial_hash() attempts
to create a unique hash value based on the issuer and serial number data
contained within an X509 certificate. However it fails to correctly
handle any errors that may occur while parsing the issuer field (which
might occur if the issuer field is maliciously constructed). This may
subsequently result in a NULL pointer deref and a crash leading to a
potential denial of service attack.
The function X509_issuer_and_serial_hash() is never directly called by
OpenSSL itself so applications are only vulnerable if they use this
function directly and they use it on certificates that may have been
obtained from untrusted sources.
CVE-2021-23841
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(cherry picked from commit 8130d654d1de922ea224fa18ee3bc7262edc39c0)
|
|
This (re-)allows RSA-PSS signers
Fixes #13931
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13982)
|
|
SRP_Calc_client_key calls BN_mod_exp with private data. However it was
not setting BN_FLG_CONSTTIME and therefore not using the constant time
implementation. This could be exploited in a side channel attack to
recover the password.
Since the attack is local host only this is outside of the current OpenSSL
threat model and therefore no CVE is assigned.
Thanks to Mohammed Sabt and Daniel De Almeida Braga for reporting this
issue.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13889)
|
|
...in case the candidate issuer cert is identical to the target cert.
Fixes #13739
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13749)
|
|
to invalid cert
This is the backport of #13755 to v1.1.1.
Fixes #13698
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13756)
|
|
Fixes #13840
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13857)
(cherry picked from commit 4369a882a565c42673b28c586a5c46a8bca98d17)
|
|
when possible using the getauxval equivalent which has similar ids as Linux, instead of bad instructions catch approach.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13650)
(cherry picked from commit 5eb24fbd1c3e0d130ba7f81f1ccf457a2b9d75ad)
|
|
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13821)
(cherry picked from commit b57ec7394aace731c460b509aa84039274337600)
|
|
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/13772)
|
|
I.e.:
error: out of range immediate fixup value
This fix is identical to one of the changes made in 3405db9, which I
discovered right after taking a quick stab at fixing this.
CLA: trivial
Fixes #7878
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13757)
|
|
This backports #13764.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/13769)
|
|
Backport of #13394
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/13637)
|
|
When X509_ATTRIBUTE_create() receives an invalid NID (e.g., -1), return
failure rather than silently constructing a broken X509_ATTRIBUTE object
that might cause NULL pointer accesses later on. This matters because
X509_ATTRIBUTE_create() is used by API functions like PKCS7_add_attribute(3)
and the NID comes straight from the user.
This bug was found while working on LibreSSL documentation.
Reviewed-by: Theo Buehler <tb@openbsd.org>
CLA: trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12052)
(cherry picked from commit c4b2c53fadb158bee34aef90d5a7d500aead1f70)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
It never makes sense for multi-string or CHOICE types to have implicit
tagging. If we have a template that uses the in this way then we
should immediately fail.
Thanks to David Benjamin from Google for reporting this issue.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
|
|
It never makes sense for multi-string or CHOICE types to use implicit
tagging since the content would be ambiguous. It is an error in the
template if this ever happens. If we detect it we should stop parsing.
Thanks to David Benjamin from Google for reporting this issue.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
|
|
If a GENERAL_NAME field contained EdiPartyName data then it was
incorrectly being handled as type "other". This could lead to a
segmentation fault.
Many thanks to David Benjamin from Google for reporting this issue.
CVE-2020-1971
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
|
|
EDIPartyName has 2 fields that use a DirectoryString. However they were
marked as implicit tagging - which is not correct for a CHOICE type.
Additionally the partyName field was marked as Optional when, according to
RFC5280 it is not.
Many thanks to github user @filipnavara for reporting this issue. Also to
David Benjamin from Google who independently identified and reported it.
Fixes #6859
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
|
|
The certificate path validation procedure specified in RFC 5280 does not
include checking the validity period of the trusted (root) certificate.
Still it is common good practice to perform this check.
Also OpenSSL did this until version 1.1.1h, yet
commit e2590c3a162eb118c36b09c2168164283aa099b4 accidentally killed it.
The current commit restores the previous behavior.
It also removes the cause of that bug, namely counter-intuitive design
of the internal function check_issued(), which was complicated by checks
that actually belong to some other internal function, namely find_issuer().
Moreover, this commit adds a regression check and proper documentation of
the root cert validity period check feature, which had been missing so far.
Fixes #13471
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13585)
|