Skip navigation
Share This:

The OpenSSL project have released information on what has been called the DROWN attack.

 

In summary - SSLv2 is dead, gone, kaput. Well, unless you build OpenSSL specifically with SSLv2 enabled. Also the SSLv2 export ciphers are removed.

 

There are a large number of vulnerabilities in SSLv2 (see the OpenSSL advisory for some of them) so it's surprising that it's taken so long to be honest and, according to the attack website, at least a quarter of the top 1 million domains are still vulnerable. Yowser.

 

So ... to ADDM Discovery. The openssl on RHEL6 is affected - as in it has not had SSLv2 disabled - as is the version of the OpenSSL libraries we use in the proxy. However, SSLv2 is disabled on the Apache server and the appliance-proxy communication uses TLSv1.2 so ADDM Discovery is not vulnerable to the attack.

 

The vulnerability has been classed "Important" by Red Hat and has a CVSS of 5.8. These factors combined mean we will package up the openssl RPM change in the next OSU (after it's available from Red Hat) and the proxy build will be updated for next releases.

Share This:

The Google Security Team and Red Hat have found what is deemed a critical security issue (CVE-2015-7547). A vulnerability in glibc means a craftily crafted DNS response can cause a buffer overflow and cause a crash (libresolv) or execution of code with permissions of the user running libresolv. This affects more apps then you'd expect - for example the reverse lookups done during ssh connections!

 

ADDM may be affected. Red Hat have made a patch available and we are currently testing this. Given we're so close to releasing the February OSU, we are going to pull forward rather than an emergency release with only the one update. I will update the blog post as soon as the OSU is ready.

 

More detailed information about the vulnerability:

Red Hat Article: https://access.redhat.com/articles/2161461

Google Article: https://googleonlinesecurity.blogspot.nl/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html

Mitre CVE:  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547

NVD: http://https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7547

 

 

*UPDATE (19th February 2016): An RHEL6 OSU with the updated glibc packages is now available.

* UPDATE (1st March 2016): Added Mitre and NVD links.

Kerryn Wood

Those Jam logs!

Posted by Kerryn Wood Moderator Jun 4, 2015
Share This:

Another day, another codename for a security vulnerability. This time it's "LogJam". Doesn't have quite the ring of BEAST or FREAK but similar in some ways to the latter.

 

In short, a RHEL6 appliance with an OSU later than October 2014 is not susceptible to the downgrade to export-grade ciphers and uses 2048-bit DH parameters. RHEL5 appliance UIs do not allow the downgrade to export-grade ciphers and use 1024-bit DH parameters. Communication between appliances and proxies (prior to 10.2) is susceptible to downgrading and uses 512-bit DH parameters.

 

I discuss in more detail below but inter-communication between proxies and appliances is vulnerable. However, the complexity of the attack and the fact it would have to occur inside of a (hopefully) protected network limit the possibility of the vulnerability being exploited. The vulnerability poses a much more serious threat to public facing applications or sites.

 

Adrian et al, published their findings and materials on https://weakdh.org/. The WeakDH.org site and OpenSSL blog (https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/) provide excellent detail on the vulnerabilities and how to test for them and the paper itself is available if you fancy the  technical detail (https://weakdh.org/imperfect-forward-secrecy.pdf).

 

The attack is a man-in-the-middle (MiTM) attack.  A connection is "downgraded" to a weaker Diffie-Hellman (DH) group. Without going into implementation details - a higher-bit group is regarded stronger for the DH key-exchange. Pre-computing the weak groups allows the MitM to compromise a connection quickly when intercepting the initial key exchange. According to the paper, a 512-bit group was pre-computed in a week by the team and nation-states could (and probably have) compute 1024-bit groups in a time to make them useful. This is an issue because a large number of servers employing DH key-exchange use a "small number of fixed or standardized groups".

 

The WeakDH.org team have 3 recommendations for correctly deploying Diffie-Hellman for TLS (https://weakdh.org/sysadmin.html) which involves disabling the export-grade cipher suites, deploying Elliptic-Curve DH ciphers and generating strong (more importantly - unique) DH groups. Red Hat's article on LogJam (https://access.redhat.com/articles/1456263) focusses on stopping export-downgrade and information on how to stop clients accepting smaller DH parameters. OpenSSL is used by the ADDM appliance (httpd - part of the RHEL distribution) as well as for communication (omniORB) between appliances and proxies. The WeakDH.org team also recommend OpenSSH configuration changes to mitigate the fact OpenSSH also uses DH groups and this affects the appliance only.

 

Red Hat excluded export-grade ciphers in a patch to OpenSSL packages shipped in RHEL 6 from 6.6 (https://rhn.redhat.com/errata/RHBA-2014-1525.html). These packages were included in the October 2014 OSU. This means the UI on the appliance (you are using HTTPS, right? ;D) is not vulnerable to downgrade assuming an October OSU, or later, has been applied. For those customers that have followed the steps to implement mod_nss, the upstream change is currently “under investigation by Red Hat and may be backported to the relevant NSS packages”. The DH parameters are 2048-bit.

 

Unfortunately, because the CVE has been rated “Moderate Impact”, Red Hat will not be patching the OpenSSL packages on RHEL 5. That said, running the OpenSSL suggested tests for vulnerability (with suitable warning that it’s just a smoke test) shows a RHEL 5 ADDM appliance does not allow exporting ciphers and uses 1024-bit DH parameters. I suspect this is due to the SSLCipherSuite configuration.

 

Running the OpenSSL tests against the externally visible omniORB ports on an up-to-date RHEL6 appliance shows that it does not allow export-grade ciphers (it uses openssl shipped with RHEL) and uses 512-bit DH parameters. Running the same tests on the proxy side shows the proxy will allow downgrading and uses a 512-bit DH parameters. Unlike the appliance, the proxy is built against a specific version of OpenSSL (can't rely on it existing in the OS) and carries the required files to allow communication. We update the OpenSSL version as often as is feasible (latest available before release) but the fix in OpenSSL (upstream, not RH) was not available in any of the current releases at the time we built the proxies. From 10.2, the proxy does not support downgrade of the ciphers due to a tightening of the list of ciphers but earlier versions are susceptible. There are no onsite configurations that can be used to stop downgrade or increase the DH parameters.

 

In the short term, we're going to ship proxies in an upcoming OSU - making them available by the UI - that will stop downgrading to export-grade ciphers. However, increasing the size of the DH parameters will introduce a lot of upgrade and compatibility complications and further planning and testing needs to be done before we consider exactly what to do. While deploying elliptic-curve ciphers and generating additional groups is recommended by the WeakDH team it's more relevant to publicly facing applications and sites than an application inside the network. Regardless of the complexity of the attack, and the limited scope, the ADDM team are looking at ways we can help limit susceptibility further. As Schneier, the Chuck Norris of the security world (http://www.schneierfacts.com/), states; "One of the problems with patching the vulnerability is that it breaks things" (https://www.schneier.com/blog/archives/2015/05/the_logjam_and_.html),  and we want to avoid that

 

*UPDATE (5th June 2015): Of course Red Hat chose to back port a patch to the OpenSSL packages today (Red Hat Customer Portal) that enforces DH parameters >=768-bits. Essentially, this patch, once applied, will affect communication between appliance<->appliance and appliance<->proxy because the appliance relies on OpenSSL shipped with RHEL. The patch is marked Moderate severity so this will be rolled into a monthly OSU rather than an immediate patch and we will do our best to make sure the updates to the required bits of ADDM are as seamless as possible.

 

*UPDATE (15th June 2015): To clarify my above update. Red Hat's update will be included in a future OSU and that this affects only disabling cipher downgrade on the appliance - it does not increase parameters. We're looking at how best to allow for this patch and how it will work and affect ADDM - as well as how best to upgrade the appliance and proxies with as little disruption to customers as possible.  We'll have an update on how we're going to do this ASAP.

 

*UPDATE (10th July 2015): We have added the following message to the OSU June documentation.

The openssl-1.0.1e-cve-2015-4000.patch has been excluded from the openssl-1.0.1e-30.el6_6.11 RPM to prevent compatibility issues in existing BMC Atrium Discovery deployments.

The patch prevents OpenSSL allowing connections with DH parameters fewer than 768 bits. OpenSSL is used in BMC Atrium Discovery for communication between appliances for consolidation and clustering, and between appliances and Windows proxies. All these channels currently use 512 bit DH parameters. If the patch was included, no communication between appliances and proxies would be possible until all were upgraded.

Future releases of BMC Atrium Discovery will increase the DH parameters to 2048 bits. Excluding the patch at present allows planned roll-out of updates rather than a forced immediate upgrade of all systems.


*UPDATE (17th September): As of 10.2.0.1 both the appliance and proxies are using 2048 bit DH parameters (Defects resolved in this version - BMC Atrium Discovery 10.2 - BMC Documentation - ADDM-16279). We will continue to remove the openssl-1.0.1e-cve-2015-4000.patch from the openssl RPM shipped in the OSU for backwards compatibility with older proxies and appliances.


Kerryn Wood

SSH connection Gotcha!

Posted by Kerryn Wood Moderator Feb 5, 2015
Share This:

In Zythum pre-release 1 (Zythum pre-release 1 now available!) we've made a change to the SSH server installed on the ADDM appliance that may catch some of you by surprise. We're nice like that

 

We have tightened the list of supported Ciphers and HMAC algorithms that the SSH server on the ADDM appliance will allow.

 

What does this mean? Well, for the most part - with any luck - you probably won't even notice Where you will encounter issues is where you're connecting to the appliance with older versions of software that allow you to connect to the appliance with ssh. This occurs because the list of Ciphers of HMAC algorithms that is available in the software may not contain the necessary Ciphers and HMACs required to negotiate with the SSH server.

 

There are a number of ciphers and hashing algorithms that are regarded weak because some part of the cipher (which is actually a cipher-block) or the algorithm have been proved fallible. In addition, there is a limited list of ciphers and algorithms that are FIPS approved leaving us with a very limited list that we can configure the server with.

 

Internally, we encountered the issue in very few places. Updating to the latest version of the software in question fixed it for the most part. In one instance (Paramiko) we had to update to a development branch because the software was using an older 3rd party library. Latest versions of Putty, MobaXterm, mRemoteNG and ssh from Linux systems as far back as Fedora Core 5 all worked fine.

 

For those technically interested the list of supported ciphers and macs is below:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr

MACs hmac-sha2-256,hmac-sha2-512

 

Enjoy the pre-release!