Another week, another new SSL exploit

Late last week, a new SSL bug was discovered by Google Research Labs. Simply put, due to the large number of protocols, clients and servers, most clients will start with the highest supported protocol and downgrade accordingly in order to be compatible to older servers. The weakness happens in SSLv3 which is 18 years old which can allow an attacker with sufficient computing resources to guess the encrypted data. For the more technical reader, here’s a link with more details.

While exploiting this bug is fairly difficult due to the large amount of computing resources needed, once the exploit was known, our team started putting together an action plan within hours. We started off implementing a patched version of OpenSSL on all servers which support TLS_FALLBACK_SCSV. This is a mechanism that solves the problems caused by retrying failed connections and thus prevents attackers from inducing browsers to use SSL 3.0. It also prevents downgrades from TLS 1.2 to 1.1 or 1.0 and so may help prevent future attacks.

However we did not stop there. We continue to refine our response and came out with methods to disable SSLv3 on all the main servers on our clients and our own servers. This includes:

  • Apache Web Server
  • WHM / Cpanel Control Panel
  • POP3 / IMAP Mail server
  • Exim SMTP server

This ensures that SSLv3 is no longer available to be exploited even if there’s some still unknown method to exploit it.

While this may break support for older clients, we estimated this to be of very limited impact. The security advantages also fair outweighs the disadvantages. If in doubt, please feel free to contact our support team.

Bash Vulnerability – Shellshock Exploit

What is it?

Chances are, you’ve already heard about the recent discovery of what’s being called the “Shellshock” exploit in GNU Bash. This is a vulnerability that existed in Bash through versions that have span 25 years. However as it is a little used function, the exploit did not come into light till this week. The vulnerability can result in remote execution of arbitrary code.

Bash is widely used by many popular Linux distributions and Mac OS X. This means that the exposure surface is extremely large. As the bug has been in the wild for many years, it is unknown if this exploit have been used in the past.

Critical instances where the vulnerability may be exposed include:

  1. Apache HTTP Server using mod_cgi or mod_cgid scripts either written in bash, or spawn subshells.
  2. Override or Bypass ForceCommand feature in OpenSSH sshd and limited protection for some Git and Subversion deployments used to restrict shells and allows arbitrary command execution capabilities.
  3. Allow arbitrary commands to run on a DHCP client machine, various Daemons and SUID/privileged programs.
  4. Exploit servers and other Unix and Linux devices via Web requests, secure shell, telnet sessions, or other programs that use Bash to execute scripts.

Am I affected?

For servers running RHEL/CentOS 5/6/7, our team was aware of the issue the same day it was made public on 24th September. Our team worked through the night to ensure the patch was applied within hours after it was released. The first patch was incomplete and we applied a 2nd patch the next day, once again within hours after the patch is available.

With respect to the above potential issues, we will like to explain how our managed servers using our default security policies are unaffected. We have kept it general on purpose:

  1. Most of our servers do not have mod_cgi in use. On top of that, we do not run PHP under CGI wrapper. Further to that, we restrict some key functions of PHP that would have made this a more dangerous bug such as system / exec.
  2. Most of our servers do not allow external shell access. For those that do, we do not use Bash as the shell. There are also other policies limiting access to only authorized users.
  3. We disable all unnecessary services including DHCP, etc during setup.
  4. Please refer to response 2 above. Another exposure surface we can foresee is the use of cron which may allow some users to put malicious commands. However, we currently do not run these jobs under Bash as well, but is using a separate shell.

If you have a specific area or question you like to clarify, please feel free to open a ticket with us. We will be happy to address any concerns directly for our clients.

Sprintserve Net Offers Multiple PHP Versions

Sprintserve NET is happy to announce the immediate availability of multiple PHP versions. We will make available PHP 5.2, 5.3, 5.4 and 5.5, with the current default being PHP 5.2.  No action is required from you if you are happy with the current version of PHP. However we strongly encourage to test your scripts with one of the newer PHP versions.

What do I need to know: 

  • The current default PHP version 5.2.17 remains the default. No action is needed if you want to continue using this version.
  • The current alternate versions supported are PHP 5.3.28, 5.4.28 and 5.5.12.
  • We strongly encourage all clients to upgrade to a newer PHP version as PHP 5.2.17 and 5.3.28 has been deprecated. We expect to change the default version in the near future as it is no longer supported by Cpanel.
  • Please note that there are major changes between the different versions, and that it is the client’s responsibility to ensure that their scripts are compatible with the various PHP versions.
  • Upgrading from PHP 5.2 to 5.3:
  • Upgrading from PHP 5.3 to 5.4:
  • Upgrading from PHP 5.4 to 5.5:

How do I enable PHP 5.3, 5.4 or 5.5:
PHP 5.3
Add the following to your .htaccess in your home directory:
<IfModule mod_suphp.c>
AddHandler application/x-httpd-php53 .php

PHP 5.4
Add the following to your .htaccess in your home directory:
<IfModule mod_suphp.c>
AddHandler application/x-httpd-php54 .php

PHP 5.5
Add the following to your .htaccess in your home directory:
<IfModule mod_suphp.c>
AddHandler application/x-httpd-php55 .php

To reverse the change, simply remove the directives that have been added. As always feel free to contact our support if you need further assistance.

Sprintserve Net Antispam Cloud

For any of our shared server clients, most of you should be aware by now the conversion of all our emails handling over to our own cloud. For those who are still blissfully unaware, there is just one thing we like to mention in this post that’s technical. If you are using your own DNS, please send us a support ticket with the domain so that we can activate your domain in our cloud. The entries you need to edit at your DNS provider is to change all your MX entries to the following:

  • (Priority: 0)
  • (Priority: 1)

If you are procrastinating, here is just some statistics that we will share with you that may help give you some impetus to do it as soon as possible:

Antispam Cloud Statistics

Antispam Cloud Statistics – 92% spam rejection rate

For those who want to save some time, that is a spam rejection rate of about 92% of all emails received.

Some of the benefits:

  • The cloud will be geographically dispersed shortly. This will ensure your emails will still be received and queued by our cluster and it will forward to your account once your server returns.
  • We will also scan outgoing emails. This will help protect the integrity of the IPs of the server and reduce incidences of blacklisting.


For our dedicated customers, we can protect your server as well. Please contact sales and we can provide you a quote. We will take care of all the setup and conversion for you.