Bugzilla – Bug 207635
VUL-0: CVE-2006-2940: openssl: parasitic keys problem
Last modified: 2022-06-23 14:42:26 UTC
(we had this previously, but I cannot find the bug) NOT PUBLIC CRD Sep 28 2006 From: Mark J Cox <mark@awe.com> To: vendor-sec@lst.de Cc: openssl-team@openssl.org Subject: [vendor-sec] CVE-2006-2940 OpenSSL embargoed Errors-To: vendor-sec-admin@lst.de Date: Fri, 22 Sep 2006 11:15:00 +0100 (BST) [-- Anhang #1 --] [-- Typ: text/PLAIN, Kodierung: 7bit, Größe: 1,1K --] This issue was previously communicated to you via NISCC as "parasitic public keys" but without a patch. Bodo and Steven have worked on a patch, but it needs vendor testing. Patch is attached and under embargo. Dr S N Henson of the OpenSSL core team and Open Network Security recently developed an ASN1 test suite for NISCC (www.niscc.gov.uk). When the test suite was run against OpenSSL a DoS was discovered. Certain types of public key can take disproportionate amounts of time to process. This could be used by an attacker in a denial of service attack. CVE-2006-2940 Now to correct this we put in place various limits, similar to what other crypto libraries (such as NSS) do. This patch is against 0.9.8. Bodo said "Note that the ECC-related changes can be omitted for 0.9.7, since the 0.9.7 branch contains a partial ECC library, but does not integrate it into TLS and X.509!" Please follow up on any testing to openssl-team as time is tight to get this out by the embargo date, 20060928. We'll come back next week with the final set of patches for all the 20060928 OpenSSL issues. Cheers, Mark [-- Anhang #2: openssl-Bodo-CVE-2006-2940.patch --]
Created attachment 99422 [details] openssl-Bodo-CVE-2006-2940.patch
Created attachment 99526 [details] ... It seems that the last patch maybe somehow doesnt apply correctly, according to the contributor. If it fails, this one is a write-up.
Patchinfos submitted. It also covers the shared_ciphers overflow.
Raising severity because asn.1 parsing is ubiquitous. (Other problems in asn.1 parsing were found in 2003: CAN-2003-0543, CAN-2003-0544, CAN-2003-0545)
From: Markus Friedl <markus.r.friedl@arcor.de> To: Bodo Moeller <bmoeller@acm.org>, Mark J Cox <mark@awe.com>, vendor-sec@lst.de, openssl-team@openssl.org Subject: Re: [vendor-sec] CVE-2006-2940 OpenSSL embargoed User-Agent: Mutt/1.4.2i Errors-To: vendor-sec-admin@lst.de Date: Mon, 25 Sep 2006 21:33:26 +0200 On Fri, Sep 22, 2006 at 02:28:16PM +0200, Bodo Moeller wrote: > On Fri, Sep 22, 2006 at 01:29:09PM +0200, Markus Friedl wrote: > > On Fri, Sep 22, 2006 at 11:15:00AM +0100, Mark J Cox wrote: > > >> +#define OPENSSL_DH_MAX_MODULUS_BITS 3072 > > > FYI: openssh's moduli file ships with 6144 bits > > Clearly, any fixed limit can potentially cause problems for some > legitimate use, but then we don't want to overdo this problem-causing > thing and at least not get in the way of *known* legitimate use. > Do you think we're OK if we take this value of 6144 (= 3*2048), plus > some small fudge factor? http://www.ietf.org/rfc/rfc3526.txt defines a 8192-bit MODP Group for IKE, so think it needs to be increased more. what sizes do actually cause DoS problems? should the check just prevent some insane values?
From: Bodo Moeller <bmoeller@acm.org> To: Markus Friedl <markus.r.friedl@arcor.de> Cc: Mark J Cox <mark@awe.com>, vendor-sec@lst.de, openssl-team@openssl.org Subject: Re: [vendor-sec] CVE-2006-2940 OpenSSL embargoed Mail-Followup-To: Bodo Moeller <bmoeller@acm.org>, Markus Friedl <markus.r.friedl@arcor.de>, Mark J Cox <mark@awe.com>, vendor-sec@lst.de, openssl-team@openssl.org User-Agent: Mutt/1.5.9i Errors-To: vendor-sec-admin@lst.de Date: Tue, 26 Sep 2006 07:51:20 +0200 On Mon, Sep 25, 2006 at 09:33:26PM +0200, Markus Friedl wrote: > On Fri, Sep 22, 2006 at 02:28:16PM +0200, Bodo Moeller wrote: >> On Fri, Sep 22, 2006 at 01:29:09PM +0200, Markus Friedl wrote: >>> On Fri, Sep 22, 2006 at 11:15:00AM +0100, Mark J Cox wrote: >>>> +#define OPENSSL_DH_MAX_MODULUS_BITS 3072 >>> FYI: openssh's moduli file ships with 6144 bits >> Clearly, any fixed limit can potentially cause problems for some >> legitimate use, but then we don't want to overdo this problem-causing >> thing and at least not get in the way of *known* legitimate use. >> Do you think we're OK if we take this value of 6144 (= 3*2048), plus >> some small fudge factor? > http://www.ietf.org/rfc/rfc3526.txt defines a 8192-bit MODP Group > for IKE, so think it needs to be increased more. Thanks! Then I guess 10000 would be a reasonable limit ... > what sizes do actually cause DoS problems? should the check just > prevent some insane values? Yes. Any size could be used within a DoS attack, but it's much easier with ridiculously long values since the computational effort is more than linear, so a single public-key computation in a single connection can easily be used to keep the other party busy for quite a while, whereas a dozen smaller public-key computations for one certificate chain (say) could be handled much easier. The following is a new version of the CVE-2006-2940 patch. I have increased some limits (that's the only essential change), removed the redundant macro, and made the patch more flexible in that you can now use -D switches during compilation to supersede the built-in limits. As before, the patch is for the current 0.9.8 branch; the crypto/ec portion can be ignored when backporting to 0.9.7. Bodo
Created attachment 99613 [details] bodo.patch patch from last quoted mail
Created attachment 99682 [details] backported patch which fits 0.9.7{e,d,g} A word of caution regarding backports to 0.9.7: the 0.9.8 patch will apply one of the two crypto/rsa/rsa_eay.c hunks with offset in the wrong place. (the other hunk fails) Hint when looking for missing DH_F_COMPUTE_KEY symbol: it existed in 0.9.7 already, as DH_F_DH_COMPUTE_KEY.
Created attachment 99683 [details] 0.9.8a backport
I submitted the following: /work/SRC/old-versions/10.0/all/openssl -> /work/src/done/10.0 /work/SRC/old-versions/10.1/SLE/all/openssl -> /work/src/done/10.1 /work/SRC/old-versions/8.1/SLEC/all/openssl -> /work/src/done/SLEC /work/SRC/old-versions/8.1/UL/all/openssl -> /work/src/done/SLES8 /work/SRC/old-versions/9.1/SLES/all/openssl -> /work/src/done/9.1 /work/SRC/old-versions/9.2/all/openssl -> /work/src/done/9.2 /work/SRC/old-versions/9.3/all/openssl -> /work/src/done/9.3 changelog for packages containing 0.9.7/0.9.8: - an attacker could send a list of ciphers that would overrun a buffer in SSL_get_shared_ciphers() CVE-2006-3738 [#202366] - fix possible crash in SSLv2 client triggerable by a malicious server. CVE-2006-4343 [#202366] - fix mishandling of an error condition in parsing of certain invalid ASN1 structures, which could result in an infinite loop which consumes system memory. CVE-2006-2937 [#202366] - Certain types of public key can take disproportionate amounts of time to process. This could be used by an attacker in a denial of service attack. CVE-2006-2940 [#207635] respectively - an attacker could send a list of ciphers that would overrun a buffer in SSL_get_shared_ciphers() CVE-2006-3738 [#202366] - fix possible crash in SSLv2 client triggerable by a malicious server. CVE-2006-4343 [#202366] for 0.9.6g.
The issue will go public on the 28th.
updates approved, advisory released soon
I forgot to fix the compat-openssl097g packages. I did that now, and added other missing security fixes along the way: /work/SRC/old-versions/10.1/SLE/all/compat-openssl097g -> /work/src/done/10.1 - an attacker could send a list of ciphers that would overrun a buffer in SSL_get_shared_ciphers() CVE-2006-3738 [#202366] - fix possible crash in SSLv2 client triggerable by a malicious server. CVE-2006-4343 [#202366] - fix mishandling of an error condition in parsing of certain invalid ASN1 structures, which could result in an infinite loop which consumes system memory. CVE-2006-2937 [#202366] - Certain types of public key can take disproportionate amounts of time to process. This could be used by an attacker in a denial of service attack. CVE-2006-2940 [#207635] - add fix for the CVE-2006-2940 patch: the newly introduced limit on DH modulus size could lead to a crash when exerted. [#208971] - security vulnerability which could allow RSA Signature Forgery, fix from 0.9.8c. CVE-2006-4339 [#203595]
compat-openssl096g is not vulnerable?
Correct. This bug here is not in 0.9.6g. Thus, neither compat-openssl096g nor SLES8' openssl-0.9.6g needed to be fixed.
updates released this week.