Evolution and the CVE-2015-0235 (Ghost) vulnerability

This week a new security issue has arisen: the "Ghost" vulnerability in the GNU C library on Linux systems (CVE-2015-0235), and it presents only a limited risk to the service bureau.

The best writeup is the Qualys advisory, which has tons of technical information, and it's the go-to place to get your geek on.

Quick tech summary: at most 8 bytes (size of a 64-bit pointer) can be overwritten by an attacker via DNS response, and only with digits 0-9, a dot, or a NUL byte. This makes it very challenging to exploit, but Qualys says they have a proof of concept.

But most of us are concerned with fixing the issue locally, as well as assuring customers that it's been addressed.

Note: if you're my customer and I have remote access to your Linux servers, I've probably handled this for you.

  • Evolution software itself, as delivered by iSystems, is not vulnerable in any way: not at the server, not for customer. There is no conceivable threat to an Evo Remote customer's system.
  • This vulnerability impacts Linux systems only: Windows is not vulnerable.
  • All the Linux vendors have released patches, so updating your Linux DB servers is probably easy except if you're on Red Hat Enterprise Linux without an ongoing service contract. There might be a standalone security fix, but I don't know about it.
  • The most likely exploit vector is an inverse DNS lookup for the IP address of an incoming Secure Shell connection (trying to map the remote IP to a hostname), and this can be worked around very easily, including in the middle of the day.

Updating Linux

For customers on CentOS 5, 6 or 7, the update process is straightforward for the Linux system administrator:

  1. Stop all Evo services
  2. Log into the Linux DB server as root
  3. run yum update and confirm updates when requested.
  4. After updates have been applied, reboot the Linux system
  5. After the Linux system is back, restart Evo services

The time taken depends largely on how many updates it has to apply (when's the last time your Linux was updated?) and how many updates it has to download. This can surely be done in an hour, in many cases 10 or 15 minutes is plenty of time to allocate for it.

If you're running Red Hat Enterprise Linux, getting an update might be problematic (though possible); it's best to look into other mitigations.

Note: I recommend doing all parts of the update at once: do not run the yum update earlier in the day, and then reboot in the evening.

Working around SSH DNS lookups

For users who cannot patch their Linux systems, or who can't do it immediately, there's a workaround that disables the problematic DNS lookup in Secure Shell. This can be done at any time, including when Evolution is in production, including when logged in remotely via Secure Shell (really!).

  1. Login to the Linux system as root; logging in via ssh is fine
  2. Edit /etc/ssh/sshd_config
  3. Look for the token UseDNS, make sure the line is uncommented, and that the value is set to "no"
  4. Save the file
  5. Run service sshd restart

Note: restarting the Secure Shell daemon only impacts future connections: it doesn't disconnect current ones, and it certainly won't impact things like Firebird for database access.

Many service bureaus also IP-limit inbound SSH connections, which also helps to ameliorate this issue.

Other things to look for

The above is strictly about how to deal with the Linux DB server used by Evolution, but the broader enterprise probably has other things using the Linux system under the hood.

  • Firewalls
  • Networked copier/scanner systems
  • Phone systems, especially IP-based ones
  • Security/video systems
  • Network-attached storage devices

As I discover vendors who are known to be vulnerable, or known not to be vulnerable, I'll note them here. If you discover gear not mentioned here, please let me know so I can update it for everybody.

  • SonicPoint wireless access points are not vulnerable. Ref: Dell/Sonicwall KB article
  • Barracuda Networks products use the affected libc, but exploitation seems unlikely. Still, the vendor is releasing patches for all their products as a precaution rather than survey in detail what might be vulnerable. Ref: Barracuda KB.
  • Fortigate firewall products do not use the affected API call directly, nor does third-party code inside. Ref: Fortigate KB.

iSystems will speak for their own infrastructure.