12 thoughts on - Security Implications Of Openssl098e On CentOS 7

• Personally I would go round to that particular vendors office with a pipe wrench and encourage them to do better however, unless this software is transmitting credit card information then it seems that you could be safe(ish) from the regulation standpoint. It really depends on the location of the machine. Is it deep in the bowels of your high security nuclear bunker on an air gap network or is is merrily accepting incoming traffic from China? Is the software is using an appropriate SELinux policy or is it running unconfined or with SELinux turned off?

  It seems the PCI-DSS describe a set of simple rules to get IT managers thinking but they are somewhat open to interpretation. Are you abiding to the spirit of the regulations?

• The particular software requiring 0.9.8 is performing backups of the system to a remote data center.

  My concern is that, with the compatibility package installed, could this present vulnerabilities or compliance problems in Apache?

• I would guess the only way to ascertain that is with some rigorous testing. Personally I find an alternative backup method.

• TL;DR: Preload openssl from non-standard location for closed-source app only.

  Hmm, how about taking the content of the openssl098e package, put it into a directory relative to the closed source software (e.g. /opt), and create a wrapper script, similar to the following example:

  [code]
  #!/usr/bin/bash
  # This is a wrapper for app to use openssl 0.9.8 (unsafe)
  # app is in /opt/app/
  # app starter is /opt/app/bin/starter
  # ssl098e libs are in /opt/openssl098/

  export LD_LIBRARY_PATH=/opt/openssl098/
  exec /opt/app/bin/starter ${1+”$@”}
  # ${1+”$@”} expands only if at least $1 is present
  [/code]

  YMMV

  – Yamaban.

• Remember that rhel/CentOS backports fixes, so just looking version number is not reliable way to detect security issues.

  Eero

  2015-10-21 21:18 GMT+03:00 Nick Bright :

• Indeed, though I can say on CentOS 5 the required configuration to be PCI compliand is not valid in apache, and httpd will not start.

• Nick Bright wrote:
  

  Question: is the b/u software pulling, or pushing? If the latter, I think you could run it for the one IP that they back up to, and not as a daemon, and outbound only.

  And then I’d tell them that the backup site was insecure, and not meeting requirements, and that you’d stand 5cm in front of your manager’s desk, and tell him that y’all needed to look for a new vendor, one that wasn’t helping crackers get into your backup data.

  mark

• Ok, I just forget that latest PCI DSS standard requires TLSv1.2 that is not supported under CentOS/RHEL 5.

  So, you are using https to transfer credit card data?

• openssl098e appears to be parallel-installable, that is you can safely install both it and openssl on the same system and they should not clash. As others have stated since it’s supported by RedHat it will get backports of security fixes for some time to come, although it will likely not be PCI compliant because (I think, could be wrong here) it won’t support TLS1.1 or 1.2.

  You can install it, restart apache and then easily check to see if it’s affecting apache by using openssl s_client to attempt a TLS1.2
  connection to your web server, then if that works run the tests at https://www.ssllabs.com/ssltest/index.html, that should tell you everything you need to know.

  Peter

• No. openssl098e libraries have a distinct path. Apache’s mod_ssl will not load them.

• Totally unnecessary. The openssl098e libraries do not conflict with the libraries in openssl-libs. They will not be used by anything except binaries that were linked against openssl 0.9.8e at compile time.

• TL;DQ?