General reminder: If you (mis)use the "Reply" button
in your e-mail program to start a new topic, many
recipients and automated e-mail archiving systems will
file your e-mail under the case/topic of the mail you
"replied" to.
This is because your e-mail program (correctly) includes
the unique message-id of the replied-to e-mail in the
reply specifically to facilitate correct sorting and
filing of replies.
As for your question, from the description you quote
below, I would presume this issue to be outside the
FIPS-certified part of OpenSSL and thus affecting
anyone using version 0.9.8q or older with or without
the FIPS module. Upgrading to the latest 0.9.8-series
release (at least 0.9.8s for this particular issue) in
combination with the existing FIPS-certified
"FIPS-canister" is probably the appropriate response.
On 1/25/2012 4:04 PM, Gerald L Collins wrote:
Hello all,
I've been tasked to look at some security issues for our OpenSSL
implementation. We are currently at FIPS 1.2.2 and openssl 0.9.8k.
Most of the issues I was asked to look at were no issue for us, but
the below item I'm less certain about. Since we are FIPS does this
have any chance of affecting us? We do use the SSLv23_server method
in the call of SSL_CTX_new.
Uninitialized SSL 3.0 Padding - (CVE-2011-4576):
OpenSSL prior to 1.0.0f and 0.9.8s failed to clear the bytes used as
block
cipher padding in SSL 3.0 records. This affects both clients and servers
that accept SSL 3.0 handshakes: those that call SSL_CTX_new with
SSLv3_{server|client}_method or SSLv23_{server|client}_method. It does
not
affect TLS. As a result, in each record, up to 15 bytes of uninitialized
memory may be sent, encrypted, to the SSL peer. This could include
sensitive
contents of previously freed memory. However, in practice, most
deployments
do not use SSL_MODE_RELEASE_BUFFERS and therefore have a single write
buffer
per connection. That write buffer is partially filled with non-sensitive,
handshake data at the beginning of the connection and, thereafter, only
records which are longer any any previously sent record leak any
non-encrypted data. This, combined with the small number of bytes
leaked per
record, serves to limit to severity of this issue.
Thanks,
Jerry
Gerald Collins
Senior Member Technical Staff, Programmer / Analyst
CSC
8 Executive Drive, Suite 300, Fairview Heights, IL 62208 North
American Public Sector | p: +1-618-632-9252 x410 | | gcoll...@csc.com
| www.csc.com <www.csc.com>
This is a PRIVATE message. If you are not the intended recipient,
please delete without copying and kindly advise us by e-mail of the
mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of
e-mail for such purpose.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
