OpenSSL Vulnerability - CVE-2014-0224

Latest response

Good afternoon

We have been using a scanning tool (Nessus Vulnerability Scanner) to identify security vulnerabilities. It has identified two systems which were being flagged with respect to CVE-2014-0224: OpenSSL 'ChangeCipherSpec' MiTM Vulnerability' and, after the most recent errata was applied, one of the two servers is no longer being flagged with this vulnerability.

Both systems have the same version of OpenSSL (0.9.8e-27). Not sure why one of them is still being flagged and the other is not. According to the openssl.org site, 0.9.8za is the version that remediates this and they indicate that 0.9.8e is affected.

At this point, I'm unsure how to proceed and how to remediate this issue on the remaining server.

Any ideas? Thanks!!

Responses

Dan,

I would first confirm that the previous version of the library isn't still loaded by the application you are scanning (ie. package number can be newer, but an older version of library can still be loaded).

Have the hosts been restarted?

One way to check on the host is to run lsof (this is the method I use, there may be a much easier way!)

lsof | grep libssl

In the 4th column, if you see 'DEL', the process is referencing a library that is now gone.

Restart the process and the 4th column should change to 'mem' and the number in the 7th column should match the filesize of the newly installed library file.

Thanks! I will try to do some more investigation. Thanks for the idea!

Tried running the 'lsof | grep libssl' and found that they were all already "mem" and none of them were "DEL."

Also, ran 'rpm --verfiy openssl' to see if perhaps that would show any discrepencies with installed files, but this did not return anything.

Dan,

Can you confirm if the hosts have been restarted?

Which application/service is returning the error in the scan? httpd?

I am assuming you are on RHEL 5?

-edit-

Strangely there are 3 -27 variants of this package, only the very latest resolves the errata you are referring to. This is confusing, and I hope someone from Red Hat can explain why the -28 and -29 increments weren't used?.

2014-06-03 Tomas Mraz tmraz@redhat.com 0.9.8e-27.3
- fix for CVE-2014-0224 - SSL/TLS MITM vulnerability

2014-01-28 Tomas Mraz tmraz@redhat.com 0.9.8e-27.1
- replace expired GlobalSign Root CA certificate in ca-bundle.crt

2013-02-25 Tomas Mraz tmraz@redhat.com 0.9.8e-27
- fix for CVE-2013-0169 - SSL/TLS CBC timing attack (#907589)
- fix for CVE-2013-0166 - DoS in OCSP signatures checking (#908052)
- enable compression only if explicitly asked for or OPENSSL_DEFAULT_ZLIB
environment variable is set (fixes CVE-2012-4929 #857051)
- use __secure_getenv() everywhere instead of getenv() (#839735)

Source:
https://access.redhat.com/downloads/content/rhel---5/x86_64/859/openssl/0.9.8e-27.el5_10.3/x86_64/37017186/package

I would make absolutely sure that you have the latest version of this package (view the changelog of the rpm you are installing from on the command line), and on the host that you are having issues, you may need to remove the currently installed -27 version and install the latest one.. depending on how the version of the package is handled by rpm/yum.

Yes, the server has been restarted. It will be restarted again in a couple nights as part of our montly patching schedule.

The tool detecting this is Nessus Vulnerability Scan and the message we're getting is:

The remote service accepted an SSL ChangeCipherSpec message at an incorrect point in the handshake leading to weak keys being used, and then attempted to decrypt an SSL record using those weak keys.

Port 1002/tcp

I looked at the process ID listening on 1002 and it looks like an opsware service, so I'm wondering if this has something to do with our monitoring tool (HP SiteScope). I'll have to contact our ESLA team and see if they might know more about this process.

Will post my findings when I find more info.

Thanks for the info!

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.