Bugzilla – Bug 202366
VUL-0: CVE-2006-3738: openssl: buffer overflow in SSL_get_shared_ciphers()
Last modified: 2022-06-23 14:42:09 UTC
Hello Peter, this was found by google sec-folks. From: Tavis Ormandy <taviso@google.com> To: Free Software Distribution Vendors <vendor-sec@lst.de> Subject: [vendor-sec] Multiple security issues in openssl-0.9.8a Errors-To: vendor-sec-admin@lst.de Date: Mon, 28 Aug 2006 20:04:10 +0100 Hi there, a review of openssl-0.9.8a revealed some security issues. A buffer overflow exists in the SSL_get_shared_ciphers() utility function, used to generate human readable strings from the list of shared ciphers supported on an SSL connection. A web search suggests at least exim, mysql, openssl(1) and psybnc are using this function and may be affected. char *SSL_get_shared_ciphers(const SSL *s,char *buf,int len) { ... for (i=0; i<sk_SSL_CIPHER_num(sk); i++) { /* Decrement for either the ':' or a '\0' */ len--; <------------ b c=sk_SSL_CIPHER_value(sk,i); for (cp=c->name; *cp; ) { if (len-- == 0) <------------ a { *p='\0'; return(buf); } else *(p++)= *(cp++); } *(p++)=':'; } p[-1]='\0'; return(buf); } In the code above, if at the location marked a `len` is 1, len will be decremented to zero, a character will be copied to the destination buffer and then at location b len will be decremented again to -1, and thus not satisfying the end condition `len == 0`. An attacker could send a list of ciphers (you can send a long list of the same cipher to pad up to the boundary) and then by careful selection of the final ciphers overrun the buffer with data. Although it wouldnt be easy (as you have to choose from the characters in the list of available ciphers, or ':', or '\0'), this is clearly going to be exploitable in some situations. A denial of service was discovered in the sslv2 client code, where a missing check for NULL could allow a malicious ssl server to crash a connecting client. The following perl command can be used to reproduce this issue, followed by `wget https://localhost/` # perl -e 'print "\x80\xec\x04\x4d\x00\x00\x02","\x00"x"5","A"x"512"' | nc -lp 443 If there are no objections I'll suggest 5th September as an embargo date. Please credit "Tavis Ormandy and Will Drewry, Google Security Team" in any advisories relating to these issues. Thanks, Tavis. --- openssl-0.9.8a/ssl/ssl_lib.c 2005-10-01 00:38:20.000000000 +0100 +++ openssl-0.9.8a.new/ssl/ssl_lib.c 2006-08-28 19:08:37.401404000 +0100 @@ -1219,7 +1219,7 @@ char *SSL_get_shared_ciphers(const SSL * c=sk_SSL_CIPHER_value(sk,i); for (cp=c->name; *cp; ) { - if (len-- == 0) + if (len-- <= 0) { *p='\0'; return(buf); --- openssl-0.9.8a/ssl/s3_srvr.c 2005-10-01 00:38:20.000000000 +0100 +++ openssl-0.9.8a.new/ssl/s3_srvr.c 2006-08-28 19:16:39.313556000 +0100 @@ -2017,7 +2017,7 @@ int ssl3_get_client_key_exchange(SSL *s) if (kssl_ctx->client_princ) { - int len = strlen(kssl_ctx->client_princ); + size_t len = strlen(kssl_ctx->client_princ); if ( len < SSL_MAX_KRB5_PRINCIPAL_LENGTH ) { s->session->krb5_client_princ_len = len; --- openssl-0.9.8a/ssl/s2_clnt.c 2005-08-06 00:52:07.000000000 +0100 +++ openssl-0.9.8a.new/ssl/s2_clnt.c 2006-08-28 19:14:59.398605000 +0100 @@ -520,7 +520,8 @@ static int get_server_hello(SSL *s) CRYPTO_add(&s->session->peer->references, 1, CRYPTO_LOCK_X509); } - if (s->session->peer != s->session->sess_cert->peer_key->x509) + if (s->session->sess_cert == NULL + || s->session->peer != s->session->sess_cert->peer_key->x509) /* can't happen */ { ssl2_return_error(s, SSL2_PE_UNDEFINED_ERROR);
From: Mark J Cox <mjc@redhat.com> To: Tavis Ormandy <taviso@google.com> Cc: Free Software Distribution Vendors <vendor-sec@lst.de> Subject: Re: [vendor-sec] Multiple security issues in openssl-0.9.8a Errors-To: vendor-sec-admin@lst.de Date: Tue, 29 Aug 2006 12:21:25 +0100 (BST) >Hi Mark, this sounds fine, please go ahead. Done. I assigned CVE-2006-3738 to get_shared_ciphers. Not convinced a client crash connecting to a malicious server deserves a CVE name (can you think of a security context?) Mark _______________________________________________
I have added the fixes to ssl/ssl_lib.c and ssl/s2_clnt.c. I omitted the third, unrelated change to ssl/s3_srvr.c. Packages submitted to /srv/updates/openssl-sept2006/difs/_work_src_done_10.0_openssl.dif /srv/updates/openssl-sept2006/difs/_work_src_done_10.1_openssl.dif /srv/updates/openssl-sept2006/difs/_work_src_done_SLEC_openssl.dif /srv/updates/openssl-sept2006/difs/_work_src_done_SLES8_openssl.dif /srv/updates/openssl-sept2006/difs/_work_src_done_9.1_openssl.dif /srv/updates/openssl-sept2006/difs/_work_src_done_9.2_openssl.dif /srv/updates/openssl-sept2006/difs/_work_src_done_9.3_openssl.dif together with the fix for bug 203595. Factory needs to be fixed, yet (by update to 0.9.8c).
CRD is Sep 28th for this one, even after tzhe new vulnerability.
MaintenanceTracker-6022
Okay, I'm drawing back the fixes from /work/src/done, only the other fix (for bug 203595) is submitted now.
Fixes are ready to be used later on my workstation aust patchtool -p openssl -d /srv/updates/openssl-sept2006
From: Mark J Cox <mjc@redhat.com> >I assigned CVE-2006-3738 to get_shared_ciphers. Not convinced a client >crash connecting to a malicious server deserves a CVE name (can you think >of a security context?) Okay, so in the past we have assigned a CVE name to a similar issue in OpenSSL so to be consistent the SSLv2 client side crash gets CVE-2006-4343 Mark
just for the record: [-- BEGIN PGP MESSAGE --] Hello folks, We've received a report from Tavis Ormandy of the Google Security Team describing two new vulnerabilities in OpenSSL. Included at the bottom of this message is a copy of the report in its entirety for your review. We are tracking this as two issues: VU#547300 - OpenSSL SSL_get_shared_ciphers() vulnerable to buffer overflow VU#386964 - OpenSSL sslv2 client code fails to properly check for NULL We noticed that even though the reporter refers to version 0.9.8a of OpenSSL, the bugs appear in the current version as well (0.9.8c). The reporter included a set of patches in his original notification. Note that although the patches appear to be adequate, the reporter does not represent the OpenSSL development team. At this time, we are not aware of official patches from the OpenSSL maintainers but will forward them along if we receive them. The reporter states that publication of these issues has been embargoed until 2006-09-28. We will be prepared to publish vulnerability notes on these issues in conjunction with the reporter's release. We're also aware that the reporter previously sent a copy of this report to the recipients of the "vendor-sec" (vendor-sec@lst.de) mailing list. If you have any questions or comments, please let us know. Best Regards, Chad -- Chad Dougherty Vulnerability Analyst __________________________________________________________ CERT(R) Coordination Center | cert@cert.org Software Engineering Institute | Hotline : +1 412.268.7090 Carnegie Mellon University | FAX : +1 412.268.6989 Pittsburgh, PA 15213-3890 | http://www.cert.org/ ========================================================== CERT and CERT Coordination Center are registered in the U.S. Patent and Trademark Office. The Software Engineering Institute is sponsored by the U.S. Department of Defense. ---- BEGIN ORIGINAL VULNERABILITY REPORT ---- The issue described below is embargoed until September 28th. etc. etc.
swampid: 6022
Date: Sun, 24 Sep 2006 11:04:31 +0100 (BST) From: Mark J Cox <mjc@redhat.com> To: Colin Percival <cperciva@freebsd.org> Cc: Free Software Distribution Vendors <vendor-sec@lst.de>, <openssl-team@openssl.org> Subject: Re: [vendor-sec] official openssl patches? Parts/Attachments: 1 Shown 23 lines Text 2 OK ~1.2 KB Text, "" 3 OK ~1.2 KB Text, "" 4 OK ~795 bytes Text, "" ---------------------------------------- > Does anyone have official patches for all of the openssl bugs due to go > public on Thursday? Four days isn't very long to proofread the patches, > make sure they apply to older releases, build updated binaries, and write > the advisory for this. I distributed a proposed patch for CVE-2006-2940 on Friday with a note that this one could well change as it needs vendor testing and feedback. Aside from that there are three other vulnerabilities and I've attached the final patches for the other three issues, along with their descriptions in each, to this mail. CVE-2006-2937 affects 0.9.7 and 0.9.8 but not 0.9.6 or earlier CVE-2006-2940 affects all (but see note from Friday about EC in 0.9.7) CVE-2006-3738 affects all CVE-2006-4343 affects all The patches for all apart from CVE-2006-2940 are small so should apply easily to older releases with fuzz. Vendor peer review, testing, and feedback for the propsed CVE-2006-2940 patch from friday (cc openssl-team) is really needed.
Created attachment 99522 [details] ... ...
Created attachment 99523 [details] ... ....
Created attachment 99524 [details] ... ...
updates approved, advisory to be released soon. :)
I forgot to fix the compat-openssl* packages. I did that now, and added other missing security fixes along the way: /work/SRC/old-versions/10.0/all/compat-openssl096g -> /work/src/done/10.0 /work/SRC/old-versions/9.2/all/compat-openssl096g -> /work/src/done/9.2 /work/SRC/old-versions/9.3/all/compat-openssl096g -> /work/src/done/9.3 - 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] - security vulnerability which could allow RSA Signature Forgery, fix from 0.9.8c. CVE-2006-4339 [#203595] - security fix: fix SSLv2 rollback (CAN-2005-2969) [#120103] /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]
released all of the suckers now.