From rea-fbsd at codelabs.ru Sat Nov 7 13:43:50 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Sat Nov 7 13:43:58 2009 Subject: [patch] OpenSSL in base: fix CVE-2009-3555 Message-ID: <20091107134347.418A4B8035@phoenix.codelabs.ru> >Submitter-Id: current-users >Originator: Eygene Ryabinkin >Organization: Code Labs >Confidential: no >Synopsis: [patch] OpenSSL in base: fix CVE-2009-3555 >Severity: critical >Priority: high >Category: bin >Class: sw-bug >Release: FreeBSD 8.0-BETA2 amd64 >Environment: System: FreeBSD 8.0-BETA2 amd64 >Description: See [1] (not much information just now) and [2]. >How-To-Repeat: [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555 [2] http://cvs.openssl.org/fileview?f=openssl-web/news/announce.txt&v=1.52 >Fix: The following patch applies to OpenSSL both from HEAD and 8-STABLE. It completely disables renegotiation inside TLS/SSL sessions and I had verified that no renegotiations will take place with s_client and s_server. --- fix-cve-2009-3555.diff begins here --- >From 01c641ca1a88d08fea282f79ff0f1a86d5319ba7 Mon Sep 17 00:00:00 2001 From: Eygene Ryabinkin Date: Sat, 7 Nov 2009 15:45:32 +0300 Obtained-From: http://cvs.openssl.org/chngview?cn=18791 Obtained-From: http://cvs.openssl.org/chngview?cn=18794 Signed-off-by: Eygene Ryabinkin --- crypto/openssl/CHANGES | 9 +++++++++ crypto/openssl/ssl/s3_lib.c | 3 +++ crypto/openssl/ssl/s3_pkt.c | 4 +++- crypto/openssl/ssl/s3_srvr.c | 8 ++++++++ crypto/openssl/ssl/ssl.h | 1 + crypto/openssl/ssl/ssl3.h | 9 +++++---- crypto/openssl/ssl/ssl_err.c | 1 + 7 files changed, 30 insertions(+), 5 deletions(-) diff --git a/crypto/openssl/CHANGES b/crypto/openssl/CHANGES index 04d332e..cd445c9 100644 --- a/crypto/openssl/CHANGES +++ b/crypto/openssl/CHANGES @@ -2,6 +2,15 @@ OpenSSL CHANGES _______________ + Changes between 0.9.8k and 0.9.8l [5 Nov 2009] + + *) Disable renegotiation completely - this fixes a severe security + problem at the cost of breaking all renegotiation. Renegotiation + can be re-enabled by setting + OPENSSL_ENABLE_UNSAFE_LEGACY_SESSION_RENEGOTATION at + compile-time. This is really not recommended. + [Ben Laurie] + Changes between 0.9.8j and 0.9.8k [25 Mar 2009] *) Don't set val to NULL when freeing up structures, it is freed up by diff --git a/crypto/openssl/ssl/s3_lib.c b/crypto/openssl/ssl/s3_lib.c index 8916a0b..5aa7bb2 100644 --- a/crypto/openssl/ssl/s3_lib.c +++ b/crypto/openssl/ssl/s3_lib.c @@ -2592,6 +2592,9 @@ int ssl3_renegotiate(SSL *s) if (s->s3->flags & SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS) return(0); + if (!(s->s3->flags & SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION)) + return(0); + s->s3->renegotiate=1; return(1); } diff --git a/crypto/openssl/ssl/s3_pkt.c b/crypto/openssl/ssl/s3_pkt.c index 9476dcd..b98b840 100644 --- a/crypto/openssl/ssl/s3_pkt.c +++ b/crypto/openssl/ssl/s3_pkt.c @@ -985,6 +985,7 @@ start: if (SSL_is_init_finished(s) && !(s->s3->flags & SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS) && + (s->s3->flags & SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION) && !s->s3->renegotiate) { ssl3_renegotiate(s); @@ -1117,7 +1118,8 @@ start: if ((s->s3->handshake_fragment_len >= 4) && !s->in_handshake) { if (((s->state&SSL_ST_MASK) == SSL_ST_OK) && - !(s->s3->flags & SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS)) + !(s->s3->flags & SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS) && + (s->s3->flags & SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION)) { #if 0 /* worked only because C operator preferences are not as expected (and * because this is not really needed for clients except for detecting diff --git a/crypto/openssl/ssl/s3_srvr.c b/crypto/openssl/ssl/s3_srvr.c index 80b45eb..79f3706 100644 --- a/crypto/openssl/ssl/s3_srvr.c +++ b/crypto/openssl/ssl/s3_srvr.c @@ -718,6 +718,14 @@ int ssl3_get_client_hello(SSL *s) #endif STACK_OF(SSL_CIPHER) *ciphers=NULL; + if (s->new_session + && !(s->s3->flags&SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION)) + { + al=SSL_AD_HANDSHAKE_FAILURE; + SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO, ERR_R_INTERNAL_ERROR); + goto f_err; + } + /* We do this so that we will respond with our native type. * If we are TLSv1 and we get SSLv3, we will respond with TLSv1, * This down switching should be handled by a different method. diff --git a/crypto/openssl/ssl/ssl.h b/crypto/openssl/ssl/ssl.h index ff8a128..5ef11a3 100644 --- a/crypto/openssl/ssl/ssl.h +++ b/crypto/openssl/ssl/ssl.h @@ -1952,6 +1952,7 @@ void ERR_load_SSL_strings(void); #define SSL_R_NO_PRIVATE_KEY_ASSIGNED 190 #define SSL_R_NO_PROTOCOLS_AVAILABLE 191 #define SSL_R_NO_PUBLICKEY 192 +#define SSL_R_NO_RENEGOTIATION 318 #define SSL_R_NO_SHARED_CIPHER 193 #define SSL_R_NO_VERIFY_CALLBACK 194 #define SSL_R_NULL_SSL_CTX 195 diff --git a/crypto/openssl/ssl/ssl3.h b/crypto/openssl/ssl/ssl3.h index 4b1e2e9..a1a19cb 100644 --- a/crypto/openssl/ssl/ssl3.h +++ b/crypto/openssl/ssl/ssl3.h @@ -326,10 +326,11 @@ typedef struct ssl3_buffer_st #define SSL3_CT_NUMBER 7 -#define SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS 0x0001 -#define SSL3_FLAGS_DELAY_CLIENT_FINISHED 0x0002 -#define SSL3_FLAGS_POP_BUFFER 0x0004 -#define TLS1_FLAGS_TLS_PADDING_BUG 0x0008 +#define SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS 0x0001 +#define SSL3_FLAGS_DELAY_CLIENT_FINISHED 0x0002 +#define SSL3_FLAGS_POP_BUFFER 0x0004 +#define TLS1_FLAGS_TLS_PADDING_BUG 0x0008 +#define SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION 0x0010 typedef struct ssl3_state_st { diff --git a/crypto/openssl/ssl/ssl_err.c b/crypto/openssl/ssl/ssl_err.c index 24a994f..ce2a555 100644 --- a/crypto/openssl/ssl/ssl_err.c +++ b/crypto/openssl/ssl/ssl_err.c @@ -384,6 +384,7 @@ static ERR_STRING_DATA SSL_str_reasons[]= {ERR_REASON(SSL_R_NO_PRIVATE_KEY_ASSIGNED),"no private key assigned"}, {ERR_REASON(SSL_R_NO_PROTOCOLS_AVAILABLE),"no protocols available"}, {ERR_REASON(SSL_R_NO_PUBLICKEY) ,"no publickey"}, +{ERR_REASON(SSL_R_NO_RENEGOTIATION) ,"no renegotiation"}, {ERR_REASON(SSL_R_NO_SHARED_CIPHER) ,"no shared cipher"}, {ERR_REASON(SSL_R_NO_VERIFY_CALLBACK) ,"no verify callback"}, {ERR_REASON(SSL_R_NULL_SSL_CTX) ,"null ssl ctx"}, -- 1.6.3.1 --- fix-cve-2009-3555.diff ends here --- It will be very good if __FreeBSD_version will be bumped after this update, because there are some fixes for the ports that use OpenSSL, but disable renegotiation by themselves. These fixes shouldn't be applied when system OpenSSL will be updated (port was already updated to 0.9.8k). From bzeeb-lists at lists.zabbadoz.net Wed Nov 11 17:40:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Nov 11 17:40:15 2009 Subject: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley In-Reply-To: <6101e8c40907201008n62eeec05r6670a79698bc2ac7@mail.gmail.com> References: <6101e8c40907201008n62eeec05r6670a79698bc2ac7@mail.gmail.com> Message-ID: <20091111173311.T37440@maildrop.int.zabbadoz.net> On Mon, 20 Jul 2009, Oliver Pinter wrote: Hi, > http://milw0rm.com/exploits/9206 has anyone actually been able to reproduce a problem scenario with this on any supported releases (7.x or 6.x)? The only thing I gould get from that was: execve returned -1, errno=8: Exec format error Similar results applied to the scenario from http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/80742 which had been filed for a 5.x system by Wojciech A. Koszek long before the above. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From dweber at htw-saarland.de Wed Nov 11 18:52:39 2009 From: dweber at htw-saarland.de (Damian Weber) Date: Wed Nov 11 18:52:46 2009 Subject: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley In-Reply-To: <20091111173311.T37440@maildrop.int.zabbadoz.net> References: <6101e8c40907201008n62eeec05r6670a79698bc2ac7@mail.gmail.com> <20091111173311.T37440@maildrop.int.zabbadoz.net> Message-ID: On Wed, 11 Nov 2009, Bjoern A. Zeeb wrote: > Date: Wed, 11 Nov 2009 17:37:50 +0000 (UTC) > From: Bjoern A. Zeeb > To: Oliver Pinter > Cc: freebsd-security@freebsd.org, wkoszek@freebsd.org > Subject: Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of > Service Exploit 23 R D Shaun Colley > > On Mon, 20 Jul 2009, Oliver Pinter wrote: > > Hi, > > > http://milw0rm.com/exploits/9206 > > has anyone actually been able to reproduce a problem scenario with > this on any supported releases (7.x or 6.x)? > > The only thing I gould get from that was: > execve returned -1, errno=8: Exec format error > FWIW, I got another result on 6.4-STABLE FreeBSD mymachine.local 6.4-STABLE FreeBSD 6.4-STABLE #6: Sat Oct 3 13:06:12 CEST 2009 root@hypercrypt.local:/usr/obj/usr/src/sys/MYMACHINE i386 $ ./pecoff MZaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa????aaaa [I'm truncating here, ~3500 a's follow]aaaaa: File name too long -- Damian From bzeeb-lists at lists.zabbadoz.net Wed Nov 11 19:00:12 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Nov 11 19:00:19 2009 Subject: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley In-Reply-To: References: <6101e8c40907201008n62eeec05r6670a79698bc2ac7@mail.gmail.com> <20091111173311.T37440@maildrop.int.zabbadoz.net> Message-ID: <20091111185811.P37440@maildrop.int.zabbadoz.net> On Wed, 11 Nov 2009, Damian Weber wrote: > > > On Wed, 11 Nov 2009, Bjoern A. Zeeb wrote: > >> Date: Wed, 11 Nov 2009 17:37:50 +0000 (UTC) >> From: Bjoern A. Zeeb >> To: Oliver Pinter >> Cc: freebsd-security@freebsd.org, wkoszek@freebsd.org >> Subject: Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of >> Service Exploit 23 R D Shaun Colley >> >> On Mon, 20 Jul 2009, Oliver Pinter wrote: >> >> Hi, >> >>> http://milw0rm.com/exploits/9206 >> >> has anyone actually been able to reproduce a problem scenario with >> this on any supported releases (7.x or 6.x)? >> >> The only thing I gould get from that was: >> execve returned -1, errno=8: Exec format error >> > > FWIW, I got another result on 6.4-STABLE > > FreeBSD mymachine.local 6.4-STABLE FreeBSD 6.4-STABLE #6: Sat Oct 3 13:06:12 CEST 2009 root@hypercrypt.local:/usr/obj/usr/src/sys/MYMACHINE i386 > > $ ./pecoff > MZaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa????aaaa > [I'm truncating here, ~3500 a's follow]aaaaa: File name too long Not sure if you'd see it with ktrace or not; I ran into that with my tests as well and was told that it's a shell problem. try to run it from this: ------------------------------------------------------------------------ #include #include int main(int argc, char *argv[]) { if (execl("./pecoff", "./pecoff", NULL) == -1) err(1, "execl()"); return (0); } ------------------------------------------------------------------------ /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From dweber at htw-saarland.de Wed Nov 11 19:22:18 2009 From: dweber at htw-saarland.de (Damian Weber) Date: Wed Nov 11 19:22:26 2009 Subject: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley In-Reply-To: <20091111185811.P37440@maildrop.int.zabbadoz.net> References: <6101e8c40907201008n62eeec05r6670a79698bc2ac7@mail.gmail.com> <20091111173311.T37440@maildrop.int.zabbadoz.net> <20091111185811.P37440@maildrop.int.zabbadoz.net> Message-ID: On Wed, 11 Nov 2009, Bjoern A. Zeeb wrote: > Date: Wed, 11 Nov 2009 18:59:24 +0000 (UTC) > From: Bjoern A. Zeeb > To: Damian Weber > Cc: freebsd-security@freebsd.org, wkoszek@freebsd.org, > Oliver Pinter > Subject: Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of > Service Exploit 23 R D Shaun Colley > > On Wed, 11 Nov 2009, Damian Weber wrote: > > > > > > > On Wed, 11 Nov 2009, Bjoern A. Zeeb wrote: > > > > > Date: Wed, 11 Nov 2009 17:37:50 +0000 (UTC) > > > From: Bjoern A. Zeeb > > > To: Oliver Pinter > > > Cc: freebsd-security@freebsd.org, wkoszek@freebsd.org > > > Subject: Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of > > > Service Exploit 23 R D Shaun Colley > > > > > > On Mon, 20 Jul 2009, Oliver Pinter wrote: > > > > > > Hi, > > > > > > > http://milw0rm.com/exploits/9206 > > > > > > has anyone actually been able to reproduce a problem scenario with > > > this on any supported releases (7.x or 6.x)? > > > > > > The only thing I gould get from that was: > > > execve returned -1, errno=8: Exec format error > > > > > > > FWIW, I got another result on 6.4-STABLE > > > > FreeBSD mymachine.local 6.4-STABLE FreeBSD 6.4-STABLE #6: Sat Oct 3 > > 13:06:12 CEST 2009 root@hypercrypt.local:/usr/obj/usr/src/sys/MYMACHINE > > i386 > > > > $ ./pecoff > > MZaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa????aaaa > > [I'm truncating here, ~3500 a's follow]aaaaa: File name too long > > > Not sure if you'd see it with ktrace or not; I ran into that with my > tests as well and was told that it's a shell problem. > > try to run it from this: > ------------------------------------------------------------------------ > #include > #include > > int > main(int argc, char *argv[]) > { > > if (execl("./pecoff", "./pecoff", NULL) == -1) > err(1, "execl()"); > > return (0); > } > ------------------------------------------------------------------------ execl() and /usr/local/bin/bash (bash-3.2.48_1) produce same result ktrace/kdump show ... 2380 pecoff CALL open(0x8048764,0x1,0) 2380 pecoff NAMI "evilprog.exe" 2380 pecoff RET open 3 2380 pecoff CALL write(0x3,0xbfbfce80,0xfe0) 2380 pecoff GIO fd 3 wrote 4064 bytes 0x0000 4d5a 6161 6161 6161 6161 6161 6161 6161 6161 |MZaaaaaaaaaaaaaaaa| 0x0012 6161 6161 6161 6161 6161 6161 6161 6161 6161 |aaaaaaaaaaaaaaaaaa| ... From rea-fbsd at codelabs.ru Wed Nov 11 19:37:52 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Nov 11 19:37:58 2009 Subject: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley In-Reply-To: References: <6101e8c40907201008n62eeec05r6670a79698bc2ac7@mail.gmail.com> <20091111173311.T37440@maildrop.int.zabbadoz.net> Message-ID: Wed, Nov 11, 2009 at 07:14:48PM +0100, Damian Weber wrote: > FWIW, I got another result on 6.4-STABLE > > FreeBSD mymachine.local 6.4-STABLE FreeBSD 6.4-STABLE #6: Sat Oct 3 13:06:12 CEST 2009 root@hypercrypt.local:/usr/obj/usr/src/sys/MYMACHINE i386 > > $ ./pecoff > MZaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa????aaaa > [I'm truncating here, ~3500 a's follow]aaaaa: File name too long You have no pecoff module loaded or compiled-in to the kernel, aren't you? Your "File name too long" is spitted by the shell, so it was not handled by the PE loader at all. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From wkoszek at freebsd.org Wed Nov 11 23:30:34 2009 From: wkoszek at freebsd.org (Wojciech A. Koszek) Date: Wed Nov 11 23:42:27 2009 Subject: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley In-Reply-To: <20091111173311.T37440@maildrop.int.zabbadoz.net> References: <6101e8c40907201008n62eeec05r6670a79698bc2ac7@mail.gmail.com> <20091111173311.T37440@maildrop.int.zabbadoz.net> Message-ID: <20091111230727.GB91162@FreeBSD.org> On Wed, Nov 11, 2009 at 05:37:50PM +0000, Bjoern A. Zeeb wrote: > On Mon, 20 Jul 2009, Oliver Pinter wrote: > > Hi, > >> http://milw0rm.com/exploits/9206 > > has anyone actually been able to reproduce a problem scenario with > this on any supported releases (7.x or 6.x)? > > The only thing I gould get from that was: > execve returned -1, errno=8: Exec format error > > Similar results applied to the scenario from > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/80742 > which had been filed for a 5.x system by Wojciech A. Koszek long > before the above. > Hello, This report has been lying in the PR database for a long time. I removed PECOFF from CURRENT some time ago, since absolutely noone was able to give any sensible argument for keeping PECOFF handler. Because PECOFF has been introduced years before I became a commiter, I wasn't sure if MFC is a good idea back then. The reason I didn't perform MFC to stable releases after "newer" report is our merge policy. I simply haven't yet studied it. We can consider PECOFF bug as having "security implications", but in order to make it "active", someone has to study NOTES and enable this option. For the first glance I see that ports/ situation didn't change -- we seem to have 0 ports requiring PECOFF to be present. And I can't right now confirm whether the bug is still there -- I have no 6.x and 7.x systems for testing anymore. If you want to try my code out (available in the PR), compile PECOFF -- I remember that I provided some sample case to panic the kernel. I think the best way would be to remove PECOFF from 6.x and 7.x. Thanks for CCing me. -- Wojciech A. Koszek wkoszek@FreeBSD.org http://FreeBSD.czest.pl/~wkoszek/ From dweber at htw-saarland.de Thu Nov 12 07:45:47 2009 From: dweber at htw-saarland.de (Damian Weber) Date: Thu Nov 12 07:45:54 2009 Subject: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley In-Reply-To: References: <6101e8c40907201008n62eeec05r6670a79698bc2ac7@mail.gmail.com> <20091111173311.T37440@maildrop.int.zabbadoz.net> Message-ID: On Wed, 11 Nov 2009, Eygene Ryabinkin wrote: > Date: Wed, 11 Nov 2009 22:37:44 +0300 > From: Eygene Ryabinkin > To: Damian Weber > Cc: Bjoern A. Zeeb , > freebsd-security@freebsd.org, wkoszek@freebsd.org, > Oliver Pinter > Subject: Re: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of > Service Exploit 23 R D Shaun Colley > > Wed, Nov 11, 2009 at 07:14:48PM +0100, Damian Weber wrote: > > FWIW, I got another result on 6.4-STABLE > > > > FreeBSD mymachine.local 6.4-STABLE FreeBSD 6.4-STABLE #6: Sat Oct 3 13:06:12 CEST 2009 root@hypercrypt.local:/usr/obj/usr/src/sys/MYMACHINE i386 > > > > $ ./pecoff > > MZaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa????aaaa > > [I'm truncating here, ~3500 a's follow]aaaaa: File name too long > > You have no pecoff module loaded or compiled-in to the kernel, > aren't you? Your "File name too long" is spitted by the shell, > so it was not handled by the PE loader at all. Confirmed. The code crashes the 6.4-stable machine when pecoff module is loaded. Wojciech A. Koszek wrote: > I think the best way would be to remove PECOFF from 6.x and 7.x. Now, I'm inclined to think that, too ;-) -- Damian From da at lonx.net Tue Nov 17 12:13:16 2009 From: da at lonx.net (Daniel) Date: Tue Nov 17 12:13:24 2009 Subject: Openssl TLS Reneg "Bug" Message-ID: <1e50fb510911170347t59ba964dhf3110980a5e70161@mail.gmail.com> Dear List, new here so sorry if I am missing any important points. I was wondering#: Does anyone know of the status of the "amended" openssl packages for FreeBSD. I'd like to try running our site with "reneg off", but I can't seem to find any notion of this on freebsd sites ? Any ideas, pointers ? Best Daniel From m.seaman at infracaninophile.co.uk Wed Nov 18 07:19:02 2009 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Wed Nov 18 07:19:09 2009 Subject: Openssl TLS Reneg "Bug" In-Reply-To: <1e50fb510911170347t59ba964dhf3110980a5e70161@mail.gmail.com> References: <1e50fb510911170347t59ba964dhf3110980a5e70161@mail.gmail.com> Message-ID: <4B039FDF.4010704@infracaninophile.co.uk> Daniel wrote: > Dear List, > new here so sorry if I am missing any important points. I was > wondering#: Does anyone know of the status of the "amended" openssl > packages for FreeBSD. I'd like to try running our site with "reneg > off", but I can't seem to find any notion of this on freebsd sites ? > Any ideas, pointers ? The only way of doing that at present is to use openssl-0.9.8l which has simply had the renegotiation stuff diked out of it. That's available as the security/openssl port, but be aware that you will have to rebuild any SSL-aware application to link against the shlibs it installs. The fix in 0.9.8l is an interim measure which cripples certain openssl functionality: installing it may cause websites to malfunction, so make sure you have good backups and have thought about how you can back the change out if needed. openssl-0.9.8m will provide the corrected renegotiation mechanisms as described in https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt However, 0.9.8m has not yet been released. I'd assume that this will probably be the subject of a FreeBSD Security Advisory once the fixes are available, and that supported FreeBSD branches will be updated to 0.9.8m or otherwise patched to the same effect in the base system. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20091118/4e898e6b/signature.pgp From rea-fbsd at codelabs.ru Thu Nov 19 15:19:25 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Nov 19 15:20:02 2009 Subject: Openssl TLS Reneg "Bug" In-Reply-To: <1e50fb510911170347t59ba964dhf3110980a5e70161@mail.gmail.com> References: <1e50fb510911170347t59ba964dhf3110980a5e70161@mail.gmail.com> Message-ID: Tue, Nov 17, 2009 at 12:47:14PM +0100, Daniel wrote: > new here so sorry if I am missing any important points. I was > wondering#: Does anyone know of the status of the "amended" openssl > packages for FreeBSD. I'd like to try running our site with "reneg > off", but I can't seem to find any notion of this on freebsd sites ? > Any ideas, pointers ? OpenSSL port was updated to 0.9.8l: http://www.freebsd.org/cgi/cvsweb.cgi/ports/security/openssl/Makefile?rev=1.158;content-type=text%2Fx-cvsweb-markup OpenSSL in the base system wasn't patched, according to the svn.frebsd.org. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From bz at FreeBSD.org Sun Nov 22 22:10:11 2009 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Sun Nov 22 23:49:42 2009 Subject: HEADS UP: removal of PECOFF support in RELENG_[67] Message-ID: <20091122215953.L37440@maildrop.int.zabbadoz.net> Hi, I'd like to give you a heads up that I intend to also remove PECOFF support from the stable/7 and stable/6 branches. PECOFF support is non-working and unmaintained in those FreeBSD releases and has lately still seen public security problems. PECOFF support is already gone in the upcoming 8.0 RELEASE or the 9-CURRENT development branch. Should no valid complaints come up saying that someone needs (and actively uses *cough* PECOFF support on FreeBSD it'll be removed earliest Novemeber 29th 2009 00:00 UTC (in about one week). /bz -- Bjoern A. Zeeb It will not break if you know what you are doing.