Date: Sat, 22 Mar 2003 14:04:43 +0100 From: dirk.meyer@dinoex.sub.org (Dirk Meyer) To: freebsd-security@FreeBSD.ORG, portsmgr@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory FreeBSD-SA-03:06.openssl Message-ID: <SwUKKpX9Sw@dmeyer.dinoex.sub.org> References: <200303212052.h2LKqYWw013362@freefall.freebsd.org> <200303212052.h2LKqYWw013362@freefall.freebsd.org> <20030322.210923.71081935.tsuyoshi@is.s.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
ITO Tsuyoshi schrieb:, > Will the fix for the problem (2) be included in ports/security/openssl > in 4.8-RELEASE? The ports tree has been tagged RELEASE_4_8_0 already, > and the fix for the problem (2) is not yet included. If it is not, > people should be careful not to overwrite OpenSSL in the base with the > one in the port. port is updated, but not yet committed. I will commit it after the freeze is lifted. It is not as critical as the last advisory. Its portsmgr decision to retag. (CC with this mail) preview is at: http://people.freebsd.org/~dinoex/ports/ patch included: kind regards Dirk - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany - [dirk.meyer@dinoex.sub.org],[dirk.meyer@guug.de],[dinoex@FreeBSD.org] Index: openssl/Makefile =================================================================== RCS file: /home/pcvs/ports/security/openssl/Makefile,v retrieving revision 1.79 diff -u -r1.79 Makefile --- openssl/Makefile 19 Mar 2003 06:26:52 -0000 1.79 +++ openssl/Makefile 22 Mar 2003 13:03:35 -0000 @@ -7,7 +7,7 @@ PORTNAME= openssl PORTVERSION= 0.9.7a -PORTREVISION= 1 +PORTREVISION= 2 CATEGORIES= security devel MASTER_SITES= http://www.openssl.org/source/ \ ftp://ftp.openssl.org/source/ \ Index: openssl/files/patch-ssl-s3_srvr.c =================================================================== RCS file: openssl/files/patch-ssl-s3_srvr.c diff -N openssl/files/patch-ssl-s3_srvr.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openssl/files/patch-ssl-s3_srvr.c 22 Mar 2003 13:03:35 -0000 @@ -0,0 +1,53 @@ +--- ssl/s3_srvr.c 29 Nov 2002 11:31:51 -0000 1.85.2.14 ++++ ssl/s3_srvr.c 19 Mar 2003 18:00:00 -0000 +@@ -1447,7 +1447,7 @@ + if (i != SSL_MAX_MASTER_KEY_LENGTH) + { + al=SSL_AD_DECODE_ERROR; +- SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE,SSL_R_BAD_RSA_DECRYPT); ++ /* SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE,SSL_R_BAD_RSA_DECRYPT); */ + } + + if ((al == -1) && !((p[0] == (s->client_version>>8)) && (p[1] == (s->client_version & 0xff)))) +@@ -1463,30 +1463,29 @@ + (p[0] == (s->version>>8)) && (p[1] == (s->version & 0xff)))) + { + al=SSL_AD_DECODE_ERROR; +- SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE,SSL_R_BAD_PROTOCOL_VERSION_NUMBER); +- goto f_err; ++ /* SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE,SSL_R_BAD_PROTOCOL_VERSION_NUMBER); */ ++ ++ /* The Klima-Pokorny-Rosa extension of Bleichenbacher's attack ++ * (http://eprint.iacr.org/2003/052/) exploits the version ++ * number check as a "bad version oracle" -- an alert would ++ * reveal that the plaintext corresponding to some ciphertext ++ * made up by the adversary is properly formatted except ++ * that the version number is wrong. To avoid such attacks, ++ * we should treat this just like any other decryption error. */ ++ p[0] = (char)(int) "CAN-2003-0131 patch 2003-03-19"; + } + } + + if (al != -1) + { +-#if 0 +- goto f_err; +-#else + /* Some decryption failure -- use random value instead as countermeasure + * against Bleichenbacher's attack on PKCS #1 v1.5 RSA padding +- * (see RFC 2246, section 7.4.7.1). +- * But note that due to length and protocol version checking, the +- * attack is impractical anyway (see section 5 in D. Bleichenbacher: +- * "Chosen Ciphertext Attacks Against Protocols Based on the RSA +- * Encryption Standard PKCS #1", CRYPTO '98, LNCS 1462, pp. 1-12). +- */ ++ * (see RFC 2246, section 7.4.7.1). */ + ERR_clear_error(); + i = SSL_MAX_MASTER_KEY_LENGTH; + p[0] = s->client_version >> 8; + p[1] = s->client_version & 0xff; + RAND_pseudo_bytes(p+2, i-2); /* should be RAND_bytes, but we cannot work around a failure */ +-#endif + } + + s->session->master_key_length= Index: openssl-beta/Makefile =================================================================== RCS file: /home/pcvs/ports/security/openssl-beta/Makefile,v retrieving revision 1.84 diff -u -r1.84 Makefile --- openssl-beta/Makefile 19 Mar 2003 06:28:03 -0000 1.84 +++ openssl-beta/Makefile 22 Mar 2003 13:03:39 -0000 @@ -10,7 +10,7 @@ PORTREVISION!= date -v-1d +%Y%m%d .else PORTVERSION= 0.9.7a -PORTREVISION= 1 +PORTREVISION= 2 .endif CATEGORIES= security devel .ifdef OPENSSL_SNAPSHOT Index: openssl-beta/files/patch-ssl-s3_srvr.c =================================================================== RCS file: openssl-beta/files/patch-ssl-s3_srvr.c diff -N openssl-beta/files/patch-ssl-s3_srvr.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openssl-beta/files/patch-ssl-s3_srvr.c 22 Mar 2003 13:03:39 -0000 @@ -0,0 +1,53 @@ +--- ssl/s3_srvr.c 29 Nov 2002 11:31:51 -0000 1.85.2.14 ++++ ssl/s3_srvr.c 19 Mar 2003 18:00:00 -0000 +@@ -1447,7 +1447,7 @@ + if (i != SSL_MAX_MASTER_KEY_LENGTH) + { + al=SSL_AD_DECODE_ERROR; +- SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE,SSL_R_BAD_RSA_DECRYPT); ++ /* SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE,SSL_R_BAD_RSA_DECRYPT); */ + } + + if ((al == -1) && !((p[0] == (s->client_version>>8)) && (p[1] == (s->client_version & 0xff)))) +@@ -1463,30 +1463,29 @@ + (p[0] == (s->version>>8)) && (p[1] == (s->version & 0xff)))) + { + al=SSL_AD_DECODE_ERROR; +- SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE,SSL_R_BAD_PROTOCOL_VERSION_NUMBER); +- goto f_err; ++ /* SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE,SSL_R_BAD_PROTOCOL_VERSION_NUMBER); */ ++ ++ /* The Klima-Pokorny-Rosa extension of Bleichenbacher's attack ++ * (http://eprint.iacr.org/2003/052/) exploits the version ++ * number check as a "bad version oracle" -- an alert would ++ * reveal that the plaintext corresponding to some ciphertext ++ * made up by the adversary is properly formatted except ++ * that the version number is wrong. To avoid such attacks, ++ * we should treat this just like any other decryption error. */ ++ p[0] = (char)(int) "CAN-2003-0131 patch 2003-03-19"; + } + } + + if (al != -1) + { +-#if 0 +- goto f_err; +-#else + /* Some decryption failure -- use random value instead as countermeasure + * against Bleichenbacher's attack on PKCS #1 v1.5 RSA padding +- * (see RFC 2246, section 7.4.7.1). +- * But note that due to length and protocol version checking, the +- * attack is impractical anyway (see section 5 in D. Bleichenbacher: +- * "Chosen Ciphertext Attacks Against Protocols Based on the RSA +- * Encryption Standard PKCS #1", CRYPTO '98, LNCS 1462, pp. 1-12). +- */ ++ * (see RFC 2246, section 7.4.7.1). */ + ERR_clear_error(); + i = SSL_MAX_MASTER_KEY_LENGTH; + p[0] = s->client_version >> 8; + p[1] = s->client_version & 0xff; + RAND_pseudo_bytes(p+2, i-2); /* should be RAND_bytes, but we cannot work around a failure */ +-#endif + } + + s->session->master_key_length= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?SwUKKpX9Sw>