| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A bug in the implementation of the Tonelli-Shanks algorithm can lead to
an infinite loop. This loop can be hit in various ways, in particular on
decompressing an elliptic curve public key via EC_POINT_oct2point() - to
do this, one must solve y^2 = x^3 + ax + b for y, given x.
If a certificate uses explicit encoding for elliptic curve parameters,
this operation needs to be done during certificate verification, leading
to a DoS. In particular, everything dealing with untrusted certificates
is affected, notably TLS servers explicitly configured to request
client certificates (httpd, smtpd, various VPN implementations, ...).
Ordinary TLS servers do not consume untrusted certificates.
The problem is that we cannot assume that x^3 + ax + b is actually a
square on untrusted input and neither can we assume that the modulus
p is a prime. Ensuring that p is a prime is too expensive (it would
likely itself lead to a DoS). To avoid the infinite loop, fix the logic
to be more resilient and explicitly limit the number of iterations that
can be done. The bug is such that the infinite loop can also be hit for
primes = 3 (mod 4) but fortunately that case is optimized earlier.
It's also worth noting that there is a size bound on the field size
enforced via OPENSSL_ECC_MAX_FIELD_BITS (= 661), which help mitigate
further DoS vectors in presence of this fix.
Reported by Tavis Ormandy and David Benjamin, Google
Patch based on the fixes by David Benjamin and Tomas Mraz, OpenSSL
ok beck inoguchi
This is errata/6.9/032_bignum.patch.sig
|
|
|
|
|
|
| |
ok sthen, beck, jsing, tb, etc etc
This cannot be issued as an errata/syspatch, because syspatch cannot
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to work around the expired DST Root CA X3 certficiate, enable
X509_V_FLAG_TRUSTED_FIRST in the legacy verifier. This means that the
default chain provided by Let's Encrypt will stop at the ISRG Root X1
intermediate, rather than following the DST Root CA X3 intermediate.
Note that the new verifier does not suffer from this issue, so only a
small number of things will hit this code path.
ok millert@ robert@ tb@
this is errata 6.9/018_cert
|
|
|
|
|
|
|
|
|
|
|
|
| |
The length checks need to be >= rather than > in order to ensure the string
remains NUL terminated. While here consistently check wi before using it
so we have the same idiom throughout this function.
Issue reported by GoldBinocle on GitHub.
ok deraadt@ tb@
this is 6.9 errata 017
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
X509_CERT_AUX_print().
Commit in -current:
CVSROOT: /cvs
Module name: src
Changes by: schwarze@cvs.openbsd.org 2021/07/10 11:45:16
Modified files:
lib/libcrypto/asn1: t_x509a.c
Log message:
Fix a read buffer overrun in X509_CERT_AUX_print(3),
which by implication also affects X509_print(3).
The ASN1_STRING_get0_data(3) manual explitely cautions the reader
that the data is not necessarily NUL-terminated, and the function
X509_alias_set1(3) does not sanitize the data passed into it in
any way either, so we must assume the alias->data field is merely
a byte array and not necessarily a string in the sense of the C
language.
I found this bug while writing manual pages for these functions.
OK tb@
As an aside, note that the function still produces incomplete and
misleading results when the data contains a NUL byte in the middle
and that error handling is consistently absent throughout, even
though the function provides an "int" return value obviously intended
to be 1 for success and 0 for failure, and even though this function
is called by another function that also wants to return 1 for success
and 0 for failure and even does so in many of its code paths, though
not in others. But let's stay focussed. Many things would be nice
to have in the wide wild world, but a buffer overflow must not be
allowed to remain in our backyard.
This is patches/6.9/common/015_x509.patch.sig
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is disappointing as a lot of work was put into the new verifier
during this cycle. However, there are still too many known bugs and
incompatibilities. It is better to be faced with known broken behavior
than with new broken behavior and to switch now rather than via errata.
This way we have another cycle to iron out the kinks and to fix some of
the remaining bugs.
ok jsing
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
alerts and where to add them.
|
| |
|
| |
|
|
|
|
| |
of pages anymore, but also cache larger regions; ok tb@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to fail gracefully on encountering a self-signed cert, curl looks
at the top-most error on the stack and needs specific SSL_R_ error codes.
This mechanism was broken when the tls13_alert_sent_cb() was added after
people complained about unhelpful unknown errors. Fix this by only setting
the error code from a fatal alert if no error has been set previously.
Issue reported by Christopher Reid
ok jsing
|
| |
|
|
|
|
| |
input from bcook@, ok and comments from tb@
|
|
|
|
| |
ok and input from tb@
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
For dynamically allocated verify parameters, param->name is only ever set
in X509_VERIFY_set1_name() where the old one is freed and the new one is
assigned via strdup(). Setting it to NULL without freeing it beforehand is
a leak.
looks correct to millert, ok inoguchi
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Leaks reported by Ilya Shipitsin.
|
| |
|
|
|
|
|
| |
similar that have no isssues. Reported by Michael Paoli. Failing
cases commented out for now.
|
|
|
|
| |
ok jsing@ tb@
|
| |
|
|
|
|
|
|
| |
diff from robert scheck
discussed with and tweaked by sthen
|
| |
|
|
|
|
| |
Reminded by inoguchi jsing
|
| |
|
| |
|
|
|
|
| |
ok bcook inoguchi jsing
|