Bug 175779 - Qualsys scan: Netscape/OpenSSL Cipher Forcing Bug
Qualsys scan: Netscape/OpenSSL Cipher Forcing Bug
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: openssl (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
http://www.contribs.org/bugzilla/show...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-14 16:24 EST by Gordon Rowell
Modified: 2009-03-26 13:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-15 05:44:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to remove 'workaround' from OP_ALL. (783 bytes, patch)
2005-12-14 16:35 EST, Charlie Brady
no flags Details | Diff

  None (edit)
Description Gordon Rowell 2005-12-14 16:24:19 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4

Description of problem:
Qualsys scan report:

Vulnerability: Netscape/OpenSSL Cipher Forcing Bug
Qualys ID : 38284
Port : 443
Diagnosis:
Netscape's SSLv3 implementation had a bug where if a
SSLv3 connection is
initially established, the first available cipher is
used. If a session is resumed,
a different cipher may be chosen if it appears in the
passed cipher list before
the session's current cipher. This bug can be used to
change ciphers on the
server.
OpenSSL contains this bug if the
SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG option is
enabled during
runtime. This option was introduced for compatibility
reasons.
The problem arises when different applications using
OpenSSL's libssl library
enable all compatibility options including
SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG, thus enabling
the bug.
Consequences: A malicious legitimate client can enforce
a ciphersuite not supported by the
server to be used for a session between the client and
the server. This can
result in disclosure of sensitive information.
Solution:
This problem can be fixed by disabling the
SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG option from the
options list of OpenSSL's libssl library. This can be done by
replacing the SSL_OP_ALL definition in the openssl/ssl.h file 
with the following line:
#define SSL_OP_ALL
(0x00000FFFL^SSL OP NETSCAPE REUSE CIPHER CHANGE BUG)
The library and all programs using this library need to
be recompiled to ensure
that the correct OpenSSL library is used during linking.

Version-Release number of selected component (if applicable):
openssl-0.9.7a-43.4

How reproducible:
Always

Steps to Reproduce:
Use Qualsys scanner to connect to Apache with SSL enabled.

Actual Results:  Report shown above.

Expected Results:  Error/warning should not appear.

Additional info:

openssl-0.9.7a-43.4.src.rpm does not have the SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG flag excluded from SSL_OP_ALL.

Further down in our bug, Charlie Brady noted:

[...]
Looks like nobody knows why that compat code is there:

http://www.mail-archive.com/openssl-dev@openssl.org/msg18059.html

Also looks like the bug which is asserted to exist does exist - the client can
switch to null cipher on reconnect.
[...]

Proposed patch to follow.
Comment 1 Charlie Brady 2005-12-14 16:35:31 EST
Created attachment 122248 [details]
Patch to remove 'workaround' from OP_ALL.

Here's a diff implementing the proposed fix.
Comment 3 Mark J. Cox (Product Security) 2005-12-15 03:54:21 EST
We don't believe this is actually a security issue, here is why:

Here is the original report of this issue:
www.mail-archive.com/openssl-dev@openssl.org/msg18047.html

Leads to further mails in the thread, including:
www.mail-archive.com/openssl-dev@openssl.org/msg18056.html

This mail shows that the original reporter made a mistake in his report
and the bypass of ciphers was in fact only allowed after a handshake
including the master key from the original connection - as is expected
behaviour. This therefore has no security consequences, and the
vulnerability scanner is showing a false positive. 

The customer should report this to Qualsys as a false positive.
Comment 4 Mark J. Cox (Product Security) 2005-12-15 04:12:46 EST
Actually re-reading the Qualsys report it seems they were not reporting the
possibility of a session reuse attack (which was disproved above), but in fact
that you'd be allowed to drop to a null cipher on the resume.  This is what is
expected according to http://www2.psy.uq.edu.au/~ftp/Crypto/ssleay/vendor-bugs.html

"SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG, when set, will cause the server side
of SSLeay's SSL to attempt to drop down to either a NULL encryption cipher or an
export cipher. Netscape clients do not always update the key when the reused
session is weaker than the initial connection."
Comment 5 Tomas Mraz 2005-12-15 05:44:54 EST
This problem will be resolved in the next release of Red Hat Enterprise Linux.
Red Hat does not currently plan to provide a resolution for this in a Red Hat
Enterprise Linux update for currently deployed systems.

With the goal of minimizing risk of change for deployed systems, and in response
to customer and partner requirements, Red Hat takes a conservative approach when
evaluating changes for inclusion in maintenance updates for currently deployed
products. The primary objectives of update releases are to enable new hardware
platform support and to resolve critical defects.
Comment 6 Gordon Rowell 2005-12-15 05:54:21 EST
Your analysis sounds fine to me, except for this part of the original report:

[...]
Consequences: A malicious legitimate client can enforce a ciphersuite not
supported by the server to be used for a session between the client and
the server.
[...]

If you can change to another cipher supported by both the server and client,
there's no issue. But if you can change to a cipher which is in the
supported_by_client list but not in the supported_by_server list, that would be
a concern.

Should this be CLOSED - WONTFIX (or NOTABUG), rather than CLOSED - NEXTRELEASE?
Comment 7 Gordon Rowell 2005-12-15 05:56:44 EST
Apologies - I did not mean to change this to NOTABUG (and didn't realise I could).
Comment 8 Tomas Mraz 2005-12-15 06:24:09 EST
Well as I think Netscape clients which require setting this SSL_OP are no longer
generally used it should be OK to remove this from SSL_OP_ALL for the next RHEL
release. However it is not worth fixing (could theoretically break existing
working configurations) for current RHEL releases.
Comment 9 Gordon Rowell 2005-12-15 06:28:08 EST
OK - just clarifying that your intention is to fix at some stage in the future.
We'll decide whether we want to patch ahead of you. Thanks everyone for the
quick turnaround. 
Comment 10 Nigel Jewell 2008-08-29 10:29:45 EDT
This bug still appears to be open and it is affecting our Qualys scans.  Is there any intention to fix this?
Comment 11 Nigel Jewell 2008-08-29 10:49:28 EDT
Sorry - my mistake.  Please ignore comment #10 in respect to comment #5.

If we were to roll our own RPM to fix this, do you foresee any issues or unwanted side effects?
Comment 12 Tomas Mraz 2008-09-01 04:24:19 EDT
You would break compatibility with very old broken Netscape clients but I don't think they are generally used anymore.
Comment 13 Charlie Brady 2009-03-26 13:25:58 EDT
I see that this is addressed in RHEL5:

openssl-0.9.8b/include/openssl/ssl.h:#define SSL_OP_ALL                                 0x00000FF7L /* without SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG */

...
* Thu Dec 15 2005 Tomas Mraz <tmraz@redhat.com> 0.9.8a-5
- don't include SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG
  in SSL_OP_ALL (#175779)
...
Comment 14 Charlie Brady 2009-03-26 13:38:41 EDT
> The primary objectives of update releases are to enable new hardware
> platform support and to resolve critical defects.

Is not a possible attack on SSL encryption a 'critical defect'?

Note You need to log in before you can comment on or make changes to this bug.