Re: Question regarding OpenSSL Security Advisory
On Fri, Nov 19, 2010, Muhammed Shafeek wrote: > 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? > The bug is related to TLS extensions and any OpenSSL versions supporting extensions is vulnerable: however other issues are present if extension support is not present or disabled such as the renegotiation issue which was addressed in OpenSSL 0.9.8m. In fact from 0.9.8f to 0.9.8i extensions were supported but not enabled by default. >From 0.9.8j onwards extension support is enabled by default. Note that the above version numbers refer to standard versions of OpenSSL. Some custom versions (which appear on some linux distros) may have backported extension support to earlier base versions. 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
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: 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: 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: 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: 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 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 had some questions about the latest security advisory. I understand that
this applies to multi-threaded application while using ssl sessions.
If the application is written thread safe using CRYPTO_set_locking_callback
functions will the vulnerability still apply ?
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.
Please advice.
Any help on this is really appreciated.
Regards,
Nivedita
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;
>
>br
