Howdy folks, I'm no guru, but there weren't any updates for openssl and only one patch (from october) for it on the Japanese SuSE mirror. That coupled with this: rpm -qa | grep openssl openssl-0.9.6g-30 makes it look like we are vulnerable to it. I have patched the source rpm manually, but as I said I'm no guru so you are on your own if you want to use my modified patch. You will also have to add it as Source11 to the spec file and add the appropriate patch -p1 line as well. Hopefully one of the SuSE gurus will pick this up, check it, package it and release it for the masses. Steve --- openssl-engine-0.9.6g/ssl/s3_pkt.c.orig 2003-02-21 11:36:07.000000000 +0900 +++ openssl-engine-0.9.6g/ssl/s3_pkt.c 2003-02-21 11:40:36.000000000 +0900 @@ -238,6 +238,8 @@ unsigned int mac_size; int clear=0; size_t extra; + int decryption_failed_or_bad_record_mac = 0; + unsigned char *mac = NULL; rr= &(s->s3->rrec); sess=s->session; @@ -353,8 +355,11 @@ /* SSLerr() and ssl3_send_alert() have been called */ goto err; - /* otherwise enc_err == -1 */ - goto decryption_failed_or_bad_record_mac; + /* Otherwise enc_err == -1, which indicates bad padding + * (rec->length has not been changed in this case). + * To minimize information leaked via timing, we will perform + * the MAC computation anyway. */ + decryption_failed_or_bad_record_mac = 1; } #ifdef TLS_DEBUG @@ -377,34 +382,54 @@ { #if 0 /* OK only for stream ciphers (then rr->length is visible from ciphertext anyway) */ al=SSL_AD_RECORD_OVERFLOW; - SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_PRE_MAC_LENGTH_TOO_LONG); - goto f_err; -#else - goto decryption_failed_or_bad_record_mac; -#endif - } - /* check the MAC for rr->input (it's in mac_size bytes at the tail) */ - if (rr->length < mac_size) - { -#if 0 /* OK only for stream ciphers */ - al=SSL_AD_DECODE_ERROR; - SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_LENGTH_TOO_SHORT); - goto f_err; -#else - goto decryption_failed_or_bad_record_mac; -#endif - } - rr->length-=mac_size; - i=s->method->ssl3_enc->mac(s,md,0); - if (memcmp(md,&(rr->data[rr->length]),mac_size) != 0) - { - goto decryption_failed_or_bad_record_mac; - } - } - /* r->length is now just compressed */ - if (s->expand != NULL) - { + SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_PRE_MAC_LENGTH_TOO_LONG); + goto f_err; + #else + decryption_failed_or_bad_record_mac = 1; + #endif + } + /* check the MAC for rr->input (it's in mac_size bytes at the tail) */ + if (rr->length >= mac_size) + { + rr->length -= mac_size; + mac = &rr->data[rr->length]; + } + else + { + /* record (minus padding) is too short to contain a MAC */ + #if 0 /* OK only for stream ciphers */ + al=SSL_AD_DECODE_ERROR; + SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_LENGTH_TOO_SHORT); + goto f_err; + #else + decryption_failed_or_bad_record_mac = 1; + rr->length = 0; + #endif + } + i=s->method->ssl3_enc->mac(s,md,0); + if (mac == NULL || memcmp(md, mac, mac_size) != 0) + { + decryption_failed_or_bad_record_mac = 1; + } + } + + if (decryption_failed_or_bad_record_mac) + { + /* A separate 'decryption_failed' alert was introduced with TLS 1.0, + * SSL 3.0 only has 'bad_record_mac'. But unless a decryption + * failure is directly visible from the ciphertext anyway, + * we should not reveal which kind of error occured -- this + * might become visible to an attacker (e.g. via a logfile) */ + al=SSL_AD_BAD_RECORD_MAC; + SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC); + goto f_err; + } + + /* r->length is now just compressed */ + if (s->expand != NULL) + { + if (rr->length > SSL3_RT_MAX_COMPRESSED_LENGTH+extra) { al=SSL_AD_RECORD_OVERFLOW; @@ -443,19 +468,12 @@ return(1); -decryption_failed_or_bad_record_mac: - /* Separate 'decryption_failed' alert was introduced with TLS 1.0, - * SSL 3.0 only has 'bad_record_mac'. But unless a decryption - * failure is directly visible from the ciphertext anyway, - * we should not reveal which kind of error occured -- this - * might become visible to an attacker (e.g. via logfile) */ - al=SSL_AD_BAD_RECORD_MAC; - SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC); f_err: ssl3_send_alert(s,SSL3_AL_FATAL,al); err: return(ret); } +const char *CAN_2003_0078_patch_ID="CAN-2003-0078 patch 2003-02-19"; static int do_uncompress(SSL *ssl) { 2003 2月 21 金曜日 09:01、Andreas Bittner さんは書きました:

was just going to ask the very same question. too late ;)

was wondering already, why nobody has asked this on the list here. its been a while since that sec adv has been published

http://www.openssl.org/news/secadv_20030219.txt

----- Original Message ----- From: "Konstantin (Kastus) Shchuka" <kastus@tsoft.com> To: <suse-security@suse.com> Sent: Friday, February 21, 2003 12:50 AM Subject: [suse-security] openssl vulnerability

...

Are SuSE openssl packages vulnerable to this: http://www.openssl.org/news/secadv_20030219.txt If they are, when we might expect to see SuSE patches? Thanks, -Kastus Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here