Workarounds for latest OpenSSL vulnerabilities

Can I use the following to mitigate against the latest OpenSSL CVEs (indicated further below):

Security advisory from OpenSSL.org recommended the use of TLS_FALLBACK_SCSV
mechanism to (Apache) web servers, to ensure that SSL 3.0 is used only when necessary

(in legacy apps). This way, attackers can no longer force a protocol downgrade.

edit Apache’s ssl.conf & look for the line containing SSLProtocol and amend it to:
                SSLProtocol all -SSLv3 –SSLv2
& issue “service httpd reload”

 
========================================================

Latest OpenSSL vulnerabilities.

•      CVE-2014-3571 - DTLS segmentation fault in dtls1_get_record.
•      CVE-2015-0206 - DTLS memory leak in dtls1_buffer_record.
•      CVE-2014-3569 - no-ssl3 configuration sets method to NULL
•      CVE-2014-3572 - ECDHE silently downgrades to ECDH [Client]
•      CVE-2015-0204 - RSA silently downgrades to EXPORT_RSA [Client]
•      CVE-2015-0205 - DH client certificates accepted without verification [Server]
•      CVE-2014-8275 - Certificate fingerprints can be modified
•      CVE-2014-3570 - Bignum squaring may produce incorrect results


[ Solution/Workaround ]
System Administrators are to check if their systems are running any vulnerable OpenSSL versions.
If they are vulnerable, GITSIR recommends to evaluate the patch before deploying to production systems.

Please refer to the advisory provided by OpenSSL for more details:
https://www.openssl.org/news/secadv_20150108.txt
sunhuxAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
btanConnect With a Mentor Exec ConsultantCommented:
In the context of the Apache server, even if SSL3 is not used the vulnerable s/w is still in the server system. The workaround in all advisory is still to patch it (instead of workaround). Also note that older version will not be supported for security update so it is best to upgrade early ...
As per our previous announcements and our Release Strategy
(https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions
1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these
releases will be provided after that date. Users of these releases are advised
to upgrade.
Fixed in OpenSSL 1.0.1k (Affected 1.0.1j, 1.0.1i, 1.0.1h, 1.0.1g, 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1)
Fixed in OpenSSL 1.0.0p (Affected 1.0.0o, 1.0.0n, 1.0.0m, 1.0.0l, 1.0.0k, 1.0.0j, 1.0.0i, 1.0.0g, 1.0.0f, 1.0.0e, 1.0.0d, 1.0.0c, 1.0.0b, 1.0.0a, 1.0.0)
Fixed in OpenSSL 0.9.8zd (Affected 0.9.8zc, 0.9.8zb, 0.9.8za, 0.9.8y, 0.9.8x, 0.9.8w, 0.9.8v, 0.9.8u, 0.9.8t, 0.9.8s, 0.9.8r, 0.9.8q, 0.9.8p, 0.9.8o, 0.9.8n, 0.9.8m, 0.9.8l, 0.9.8k, 0.9.8j, 0.9.8i, 0.9.8h, 0.9.8g, 0.9.8f, 0.9.8e, 0.9.8d, 0.9.8c, 0.9.8b, 0.9.8a, 0.9.8)
0
 
arnoldConnect With a Mentor Commented:
Yes, presumably you mean altering the ssl portion of Apache to restrict crypt/ciphers and transport version.

You can then use openssl s_client -connect to test the ciphers available/offered on a test system if you have one before moving to production.
0
 
David Johnson, CD, MVPConnect With a Mentor OwnerCommented:
you also have to implement:
OpenSSL 1.0.1 users should upgrade to 1.0.1k.
OpenSSL 1.0.0 users should upgrade to 1.0.0p.
OpenSSL 0.9.8 users should upgrade to 0.9.8zd.
0
Will You Be GDPR Compliant by 5/28/2018?

GDPR? That's a regulation for the European Union. But, if you collect data from customers or employees within the EU, then you need to know about GDPR and make sure your organization is compliant by May 2018. Check out our preparation checklist to make sure you're on track today!

 
btanConnect With a Mentor Exec ConsultantCommented:
Vulnerabilities in the openssl still exist even if fallback is done and in fact not recommended as it is workaround. Disable SSL if not used, but not a a risk of removing the secure channel unnecessarily.

Eventually, consider closing the holes if patches (esp on the Host OS running - check the availability, some are already in work) are already make available. If that is not possible, consider taking off the appl systems server offline or segregate off that services using openssl from public facing. The whole idea is to reduce exposure even though the severity level for these are at max Medium and Low, and public exploit is not known (yet)(for now).

Check the current openssl version (mostly using e.g. openssl -v) based on your system principal advice. If it is as per listed in the vulnerable list or below, consider the patch upgrade. @ https://www.openssl.org/docs/apps/version.html
0
 
btanConnect With a Mentor Exec ConsultantCommented:
in fact latest vulnerability did not surface in the Apache buzilla though ... below is just a open search for openssl and cve related @ https://issues.apache.org/bugzilla/buglist.cgi?bug_status=__open__&content=openssl%20CVE&no_redirect=1&order=changeddate%2Cpriority%2Cbug_severity&product=&query_based_on=&query_format=specific

Recalling past Heartbleed, there is record in bugzilla for patching Apache openssl. Likely the same approach in separate patch will need to be advised. https://issues.apache.org/bugzilla/show_bug.cgi?id=56363

But do note the Apacher APR and Native library (http://tomcat.apache.org/native-doc/) which uses OpenSSL as well, it was mentioned in the bugzilla above to patch that inclusively too..
0
 
gheistConnect With a Mentor Commented:
Not relevant at all:
      CVE-2014-3571 - DTLS segmentation fault in dtls1_get_record.
      CVE-2015-0206 - DTLS memory leak in dtls1_buffer_record.
Debian recompiled OpenSSL without any SSL3 and hit this bug, no debian no pain, yes debian - patch
      CVE-2014-3569 - no-ssl3 configuration sets method to NULL
Normally apache is not SSL client, at least not for untrusted sites.
      CVE-2014-3572 - ECDHE silently downgrades to ECDH [Client]
      CVE-2015-0204 - RSA silently downgrades to EXPORT_RSA [Client]
Those are relevant for client certificates, if none used no problem.
      CVE-2015-0205 - DH client certificates accepted without verification [Server]
      CVE-2014-8275 - Certificate fingerprints can be modified
Probably you need to factorize your private key if it was made on x86_64, though little detail is given on this:
      CVE-2014-3570 - Bignum squaring may produce incorrect results
0
 
gheistConnect With a Mentor Commented:
1) there is no configuration workaround for any of the issues
2) Yes, even for few of them that affect your installation
0
All Courses

From novice to tech pro — start learning today.