Stephen's picture
I'm wondering if this is normal, or if there is something unique about my situation.

I recently spun up the latest copy of the Turnkey Wordpress (not the RC) appliance and soon started failing security audits from our main office. Below are some of the examples:

"Based on the banner returned by the remote host, the device is running a version of PHP 5 that is prior to 5.2.7 and suffers from multiple published vulnerabilities. Some of these vulnerabilities may lead to denial of service or code execution."

"Based on the information returned from the host, the version of PHP installed is older than 5.2.10. Such versions are reportedly affected by multiple vulnerabilities"

"The version of OpenSSL installed on this host is prone to multiple vulnerabilities. They include: 1) The kssl_keytab_is_available function in ssl/kssl.c, when Kerberos is enabled but Kerberos configuration files cannot be opened, does not check a certain return value, which allows remote attackers to cause a denial of service condition, and 2) the ssl3_get_record function in ssl/s3_pkt.c allows remote attackers to cause a denial of service condition via a malformed record in a TLS connection that triggers a NULL pointer dereference, related to the minor version number."

Any idea how serious this is, or if it's possible to lock this down?
Jeremy Davis's picture

Unfortunately many auditing tools that are designed with the MS/Windows world in mind simply use version numbers as a way of checking for vulnerabilities.

In a Win environment this is an adequite and generally accepted way of doing things. In this scenario, the easiest way to fix a security issue with a Win app is to update to the latest version (which hopefully, but not always includes the security fix). This often suits users as new versions may also include new bells and whistles too. On the downside, there may be compatability issues and/or stabilty problems. It also relies on end users being completely responsible for checking and updating their software on a regular basis and does not easily allow for automation.

Linux does things differently. Linux is designed with stability and security as a prime factors This means that rather than updating to a new version (which may negatively impact the overall stability of the whole system or other components) the security fix is backported to the current version.

This has a number of benifits, and some downsides too (these sort of things are always a compromise). But it does mean that a simple version number check to confirm the state of security will not work. Basically you will need to either ignore the warnings and manually check which security fixes have been applied, or find a more advanced security auditing tool which actually checks the state of security rather than version numbers against a list.

Both php5 and openSSL are from the Ubuntu Hardy Security repositories so assuming you remain with the default versions (v5.2.4 & 0.9.8 respectively) they will be maintained with security related backported patches by Canonical (the backer of Ubuntu) until 2013. By default TKL appliances, check for and will apply these patches daily.

Dan Robertson's picture

You can look up the backports on Launchpad and see the changelogs including security fixes that were applied.  Many times you can search for a specific CVE and find which version it was fixed in.  You can then note that security vulnerability as a false positive.  I have had to do this for security assessments.

Add new comment