Re: Question regarding OpenSSL Security Advisory
In the Advisory it is mentioned that
"Users of all OpenSSL 0.9.8 releases from 0.9.8f through 0.9.8o should
update
to the OpenSSL 0.9.8p release which contains a patch to correct this issue."
What about users of OpenSSL releases before 0.9.8f ? Isn't the vulnerability
applicable there as well?
Thanks
Shafeek
> On Tue, Nov 16, 2010 at 7:15 AM, OpenSSL wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> OpenSSL Security Advisory [16 November 2010]
>>
>> TLS extension parsing race condition.
>> =
>>
>> A flaw has been found in the OpenSSL TLS server extension code parsing
>> which
>> on affected servers can be exploited in a buffer overrun attack.
>>
>> The OpenSSL security team would like to thank Rob Hulswit for reporting
>> this
>> issue.
>>
>> The fix was developed by Dr Stephen Henson of the OpenSSL core team.
>>
>> This vulnerability is tracked as CVE-2010-3864
>>
>> Who is affected?
>> =
>>
>> All versions of OpenSSL supporting TLS extensions contain this
>> vulnerability
>> including OpenSSL 0.9.8f through 0.9.8o, 1.0.0, 1.0.0a releases.
>>
>> Any OpenSSL based TLS server is vulnerable if it is multi-threaded and
>> uses
>> OpenSSL's internal caching mechanism. Servers that are multi-process
>> and/or
>> disable internal session caching are NOT affected.
>>
>> In particular the Apache HTTP server (which never uses OpenSSL internal
>> caching) and Stunnel (which includes its own workaround) are NOT affected.
>>
>> Recommendations for users of OpenSSL
>> =
>>
>> Users of all OpenSSL 0.9.8 releases from 0.9.8f through 0.9.8o should
>> update
>> to the OpenSSL 0.9.8p release which contains a patch to correct this
>> issue.
>>
>> Users of OpenSSL 1.0.0 and 1.0.0a should update to the OpenSSL 1.0.0b
>> release
>> which contains a patch to correct this issue.
>>
>> If upgrading is not immediately possible, the relevant source code patch
>> provided in this advisory should be applied.
>>
>> Patch for OpenSSL 0.9.8 releases
>>
>>
>> Index: ssl/t1_lib.c
>> ===
>> RCS file: /v/openssl/cvs/openssl/ssl/t1_lib.c,v
>> retrieving revision 1.13.2.27
>> diff -u -r1.13.2.27 t1_lib.c
>> - --- ssl/t1_lib.c 12 Jun 2010 13:18:58 - 1.13.2.27
>> +++ ssl/t1_lib.c15 Nov 2010 15:20:14 -
>> @@ -432,14 +432,23 @@
>>switch (servname_type)
>>{
>>case TLSEXT_NAMETYPE_host_name:
>> - - if (s->session->tlsext_hostname ==
>> NULL)
>> + if (!s->hit)
>>{
>> - - if (len >
>> TLSEXT_MAXLEN_host_name ||
>> - -
>> ((s->session->tlsext_hostname = OPENSSL_malloc(len+1)) == NULL))
>> +
>> if(s->session->tlsext_hostname)
>> + {
>> + *al =
>> SSL_AD_DECODE_ERROR;
>> + return 0;
>> + }
>> + if (len >
>> TLSEXT_MAXLEN_host_name)
>>{
>>*al =
>> TLS1_AD_UNRECOGNIZED_NAME;
>>return 0;
>>}
>> + if
>> ((s->session->tlsext_hostname = OPENSSL_malloc(len+1)) == NULL)
>> + {
>> + *al =
>> TLS1_AD_INTERNAL_ERROR;
>> + return 0;
>> + }
>>
>> memcpy(s->session->tlsext_hostname, sdata, len);
>>
>> s->session->tlsext_hostname[len]='\0';
>>if
>> (strlen(s->session->tlsext_hostname) != len) {
>> @@ -452,7 +461,8 @@
>>
>>}
>>else
>> - - s->servername_done =
>> strlen(s->session->tlsext_hostname) == len
>> + s->servername_done =
>> s->session->tlsext_hostname
>> + &&
>> strlen(s->session->tlsext_hostname) == len
>>&&
>> strncmp(s->session->tlsext_hostname, (char *)sdata, len) == 0;
>>
>>break;
>>
>> Patch for OpenSSL 1.0.0 releases
>>
>>
>
Re: Question regarding OpenSSL Security Advisory
Thank you David and Nivedita. I think I got it. -Pandit From: Nivedita Melinkeri To: Pandit Panburana Cc: openssl-users@openssl.org Sent: Thu, November 18, 2010 1:53:22 PM Subject: Re: Question regarding OpenSSL Security Advisory Hey Pandit, > Sorry for sending out the previous before it was complete. So here it goes >From what I understand the vulnerability can apply if: > >1) Internal session caching is not disable - This means the session cache is >mantained in SSL_CTX. >2) Internal session cache Lookup is not disabled - This means that the ssl >code >will lookup the session cache on receiving ClientHello with valid session Id. >3) Your application is designed such that you create a SSL_CTX and multiple >threads can access it. In this case multiple threads could be accessing the >same >session object (from session cache). The function ssl_parse_clienthello_tlsext >in t1_lib.c has unsynchronized access to members in session object which could >cause the vulnerability. >David/other experinced openssl users correct me if you think this >understanding >is incottect. > > Regards, Nivedita On Thu, Nov 18, 2010 at 7:26 AM, Pandit Panburana wrote: > >Hi, >> >> >> I am not clear about the condition that vulnerability when using internal >>session caching mechanism. Is it the same thing as TLS session caching or >>this >>is some thing different? >> >> >>Thank you, >>- Pandit >> >> >> From: David Schwartz >>To: openssl-users@openssl.org >>Cc: Nivedita Melinkeri >>Sent: Wed, November 17, 2010 4:15:36 AM >>Subject: Re: Question regarding OpenSSL Security Advisory >> >> >>On 11/16/2010 11:06 PM, Nivedita Melinkeri wrote: >> >>> Hi, >>> I had some questions about the latest security advisory. I understand >>> that this applies to multi-threaded application while using ssl sessions. >> >>Correct. >> >>> If the application is written thread safe using >>> CRYPTO_set_locking_callback functions will the vulnerability still apply ? >> >>If it didn't, it wouldn't be a vulnerability at all. >> >>> If the ssl code calls the locking callback function before accessing the >>> internal session cache then the vulnerability should not >>> apply to above mentioned applications. >> >>Right, it shouldn't, but it does. That's what makes it a vulnerability. Code >>not >>working under conditions where it cannot be expected to work is not a >>vulnerability, it's simply misuse. This is a vulnerability because it affects >>applications that use the code correctly. >> >>DS >> >> >>__ >>OpenSSL Projecthttp://www.openssl.org/ >>User Support Mailing Listopenssl-users@openssl.org >>Automated List Manager majord...@openssl.org >> >> >
Re: OpenSSL 1.0.0b testssl fails
On 11/18/2010 12:05 PM, Victor Duchovni wrote: > > None that are publically visible. You can check for yourself: > > No commits to the 0.9.8 branch after the release of 0.9.8p. > > http://cvs.openssl.org/chngview?cn=19996 I was aware of this. It's why I raised the question, if any of these were slated for backport, but simply not applied yet. The answer is no, so that resolves my questions. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question regarding OpenSSL Security Advisory
> > Hey Pandit, > > Sorry for sending out the previous before it was complete. So here it goes > From what I understand the vulnerability can apply if: > > 1) Internal session caching is *not* disable - This means the session > cache is mantained in SSL_CTX. > 2) Internal session cache Lookup is *not* disabled - This means that the > ssl code will lookup the session cache on receiving ClientHello with valid > session Id. > 3) Your application is designed such that you create a SSL_CTX and multiple > threads can access it. In this case multiple threads could be accessing the > same session object (from session cache). The function > ssl_parse_clienthello_tlsext in t1_lib.c has unsynchronized access to > members in session object which could cause the vulnerability. > > David/other experinced openssl users correct me if you think this > understanding is incottect. > > Regards, > Nivedita > On Thu, Nov 18, 2010 at 7:26 AM, Pandit Panburana wrote: > >> Hi, >> >>I am not clear about the condition that vulnerability when using >> internal session caching mechanism. Is it the same thing as TLS session >> caching or this is some thing different? >> >> Thank you, >> - Pandit >> >> -- >> *From:* David Schwartz >> *To:* openssl-users@openssl.org >> *Cc:* Nivedita Melinkeri >> *Sent:* Wed, November 17, 2010 4:15:36 AM >> *Subject:* Re: Question regarding OpenSSL Security Advisory >> >> On 11/16/2010 11:06 PM, Nivedita Melinkeri wrote: >> >> > Hi, >> > I had some questions about the latest security advisory. I understand >> > that this applies to multi-threaded application while using ssl >> sessions. >> >> Correct. >> >> > If the application is written thread safe using >> > CRYPTO_set_locking_callback functions will the vulnerability still apply >> ? >> >> If it didn't, it wouldn't be a vulnerability at all. >> >> > If the ssl code calls the locking callback function before accessing the >> > internal session cache then the vulnerability should not >> > apply to above mentioned applications. >> >> Right, it shouldn't, but it does. That's what makes it a vulnerability. >> Code not working under conditions where it cannot be expected to work is not >> a vulnerability, it's simply misuse. This is a vulnerability because it >> affects applications that use the code correctly. >> >> DS >> >> __ >> OpenSSL Projecthttp://www.openssl.org >> User Support Mailing Listopenssl-users@openssl.org >> Automated List Manager majord...@openssl.org >> >> >
Re: Question regarding OpenSSL Security Advisory
Hey Pandit, >From what I understand the vulnerability can apply if: 1) Internal session caching is *not* disable - This means the session cache is mantained in SSL_CTX. 2) Internal Lookup is not disabled - This means that the ssl code will lookup the session cache on receiving ClientHello with valid session Id. 3) Your application is designed such that you create a SSL_CTX and multiple threads can access it. In this case multiple threads could be accessing the same session object (from session cache). T he function in t1_lib.c On Thu, Nov 18, 2010 at 7:26 AM, Pandit Panburana wrote: > Hi, > >I am not clear about the condition that vulnerability when using > internal session caching mechanism. Is it the same thing as TLS session > caching or this is some thing different? > > Thank you, > - Pandit > > -- > *From:* David Schwartz > *To:* openssl-users@openssl.org > *Cc:* Nivedita Melinkeri > *Sent:* Wed, November 17, 2010 4:15:36 AM > *Subject:* Re: Question regarding OpenSSL Security Advisory > > On 11/16/2010 11:06 PM, Nivedita Melinkeri wrote: > > > Hi, > > I had some questions about the latest security advisory. I understand > > that this applies to multi-threaded application while using ssl sessions. > > Correct. > > > If the application is written thread safe using > > CRYPTO_set_locking_callback functions will the vulnerability still apply > ? > > If it didn't, it wouldn't be a vulnerability at all. > > > If the ssl code calls the locking callback function before accessing the > > internal session cache then the vulnerability should not > > apply to above mentioned applications. > > Right, it shouldn't, but it does. That's what makes it a vulnerability. > Code not working under conditions where it cannot be expected to work is not > a vulnerability, it's simply misuse. This is a vulnerability because it > affects applications that use the code correctly. > > DS > > __ > OpenSSL Projecthttp://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > >
Re: OpenSSL 1.0.0b testssl fails
On Thu, Nov 18, 2010 at 11:12:11AM -0600, William A. Rowe Jr. wrote: > On 11/18/2010 10:36 AM, Dr. Stephen Henson wrote: > > > > A 1.0.0c release is planned in the next few days. We're just seeing if any > > other issues arise before the release: a couple have been fixed already. > > Have any observed issues affected 0.9.8p? If so, is there a planned .8q? None that are publically visible. You can check for yourself: http://cvs.openssl.org/timeline No commits to the 0.9.8 branch after the release of 0.9.8p. http://cvs.openssl.org/chngview?cn=19996 The 1.0.0b issues are just the one reported in this thread: http://cvs.openssl.org/chngview?cn=20001 and a couple of platform variants where elimination of dead variables left non-working code referencing the eliminated variables. http://cvs.openssl.org/chngview?cn=20008 http://cvs.openssl.org/chngview?cn=20005 So far, it looks like the "20001" patch is sufficient for most platforms. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0b testssl fails
On Thu, Nov 18, 2010, William A. Rowe Jr. wrote: > On 11/18/2010 10:36 AM, Dr. Stephen Henson wrote: > > > > A 1.0.0c release is planned in the next few days. We're just seeing if any > > other issues arise before the release: a couple have been fixed already. > > Have any observed issues affected 0.9.8p? If so, is there a planned .8q? No, both the original SNAFU (the self test failure) and the other issues (all platform compilation problems so far) affect OpenSSL 1.0.0b only. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0b testssl fails
On 11/18/2010 10:36 AM, Dr. Stephen Henson wrote: > > A 1.0.0c release is planned in the next few days. We're just seeing if any > other issues arise before the release: a couple have been fixed already. Have any observed issues affected 0.9.8p? If so, is there a planned .8q? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question regarding OpenSSL Security Advisory
On 11/18/2010 7:26 AM, Pandit Panburana wrote: I am not clear about the condition that vulnerability when using internal session caching mechanism. Is it the same thing as TLS session caching or this is some thing different? The internal session caching mechanism caches TSL session information. If that doesn't answer your question, then I'm not sure what you're asking. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0b testssl fails
On Thu, Nov 18, 2010, Brodie Thiesfield wrote: > On Wed, Nov 17, 2010 at 9:38 AM, Victor Duchovni > wrote: > > On Tue, Nov 16, 2010 at 11:36:50PM +0100, Mounir IDRASSI wrote: > > > >> Under Windows (32bit and 64bit) with VC++ 2008, all tests are OK. But under > >> Ubuntu 8.04 LTS with gcc 4.2.4, I have the same error. > >> > >> I don't see anything OS specific in the changes introduced in t1_lib.c or > >> s3_srvr.c. Could it be a gcc bug? > > > > No, rather the tests on Windows are not as comprehensive as those > > on Unix. There is no tls1 test. > > So does anyone know if this test failure and quick checkin fix mean > that we should shelve the 1.0.0b release and we wait for a more fully > tested 1.0.0c? > A 1.0.0c release is planned in the next few days. We're just seeing if any other issues arise before the release: a couple have been fixed already. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question regarding OpenSSL Security Advisory
Hi, I am not clear about the condition that vulnerability when using internal session caching mechanism. Is it the same thing as TLS session caching or this is some thing different? Thank you, - Pandit From: David Schwartz To: openssl-users@openssl.org Cc: Nivedita Melinkeri Sent: Wed, November 17, 2010 4:15:36 AM Subject: Re: Question regarding OpenSSL Security Advisory On 11/16/2010 11:06 PM, Nivedita Melinkeri wrote: > Hi, > I had some questions about the latest security advisory. I understand > that this applies to multi-threaded application while using ssl sessions. Correct. > If the application is written thread safe using > CRYPTO_set_locking_callback functions will the vulnerability still apply ? If it didn't, it wouldn't be a vulnerability at all. > If the ssl code calls the locking callback function before accessing the > internal session cache then the vulnerability should not > apply to above mentioned applications. Right, it shouldn't, but it does. That's what makes it a vulnerability. Code not working under conditions where it cannot be expected to work is not a vulnerability, it's simply misuse. This is a vulnerability because it affects applications that use the code correctly. DS __ OpenSSL Projecthttp://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0b testssl fails
On Wed, Nov 17, 2010 at 9:38 AM, Victor Duchovni wrote: > On Tue, Nov 16, 2010 at 11:36:50PM +0100, Mounir IDRASSI wrote: > >> Under Windows (32bit and 64bit) with VC++ 2008, all tests are OK. But under >> Ubuntu 8.04 LTS with gcc 4.2.4, I have the same error. >> >> I don't see anything OS specific in the changes introduced in t1_lib.c or >> s3_srvr.c. Could it be a gcc bug? > > No, rather the tests on Windows are not as comprehensive as those > on Unix. There is no tls1 test. So does anyone know if this test failure and quick checkin fix mean that we should shelve the 1.0.0b release and we wait for a more fully tested 1.0.0c? Regards, Brodie __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: problem with "pem" file, no start line. centos.
On 11/18/2010 12:50 AM, Steve yongjin Shin wrote: -BEGIN RSA PRIVATE KEY- ...omitted.. -END RSA PRIVATE KEY- -BEGIN CERTIFICATE- ...omitted... -END CERTIFICATE- = so I started my vnc reflect server but, it shows error message = openssl_init: SSL_CTX_use_certificate_chain_file() failed. ssl error: error:0906D06C:PEM routines:PEM_read_bio:no start line = my test.pem file itself definitely has a start line. but, it shows that kind of error message. The program wants a private key file, not an RSA private key file. You can convert one to the other with 'openssl pkey'. openssl pkey -in my_rsa_private_key.pem -out my_private_key.pem DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
problem with "pem" file, no start line. centos.
Hi all.
I have trouble with using certificates with openssl.
os : centos5.4
kernel : 2.6.27.29
openssl-ver : 0.9.8e-fips-rhel5
At first, I created "rsa private key" and let's suppose this is test.key.
with "test.key" I generated certificate request. and lets suppose this as
test.csr
with "test.csr" I requested ssl certificate to "verisign.com"
and they gave me a certificates.
and I save it as "test.crt".
with this certificate, I try to run vnc reflect server.
my system requires "pem" file which includes rsa private key.
in here, I use openssl.
so, I concatenated test.key and test.crt as "test.pem"
when I verify test.pem with openssl,
(openssl verify test.pem), it says OK.
when I print out the contains,
(openssl x509 -in test.pem -text)
it shows
==
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
16:81:64:a4:28:ca:12:df:ab:12:f1:9f:b1:b9:35:54
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=VeriSign, Inc., OU=For Test Purposes Only. No
assurances., CN=VeriSign Trial Secure Server Root CA - G2
Validity
Not Before: Apr 1 00:00:00 2009 GMT
Not After : Mar 31 23:59:59 2029 GMT
Subject: C=US, O=VeriSign, Inc., OU=For Test Purposes Only. No
assurances., CN=VeriSign Trial Secure Server Root CA - G2
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
.omitted..
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
1.3.6.1.5.5.7.1.12:
0_.].[0Y0W0U..image/gif0!0.0...+..k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
X509v3 Subject Key Identifier:
48:19:E7:92:6F:92:9D:34:63:99:C0:F0:99:C8:D6:A5:8C:8C:7F:65
Signature Algorithm: sha1WithRSAEncryption
omitted...
-BEGIN CERTIFICATE-
..omitted.
-END CERTIFICATE-
==
when I open test.pem
this file shows.
==
-BEGIN RSA PRIVATE KEY-
...omitted..
-END RSA PRIVATE KEY-
-BEGIN CERTIFICATE-
...omitted...
-END CERTIFICATE-
=
so I started my vnc reflect server
but, it shows error message
=
openssl_init: SSL_CTX_use_certificate_chain_file() failed.
ssl error: error:0906D06C:PEM routines:PEM_read_bio:no start line
=
my test.pem file itself definitely has a start line.
but, it shows that kind of error message.
Searching google and the archives of this list turned nothing up
so I'm hoping someone here can help shed some light on this issue.
Thanks in advance.
