We nearly escaped the first month of the new year without another major security vulnerability, but just a few days ago, security researchers found another serious bug, which they named GHOST. This time it’s in the gethostbyname() function inside glibc, the GNU C library, so the name is apt. Once again, we can use Chef to easily detect and repair this vulnerability.
I originally tackled this exercise using the same approach as in my previous article on detecting and repairing Shellshock, but this one’s a bit tougher. There’s no built-in command that one can run on a system to collect the information. (It is possible to compile the C test code in the original security announcement on a system and distribute the binary by means of a cookbook_file resource, but that seems rather unwieldy.) I also didn’t particularly like some of the other approaches, like causing segmentation faults/core dumps as root in order to detect the vulnerability.
After reading the script that RedHat provides to its customers to detect this vulnerability (as documented in their security bulletin) I realized I could just parse the RPM changelog for glibc to see if it mentions the CVE # for GHOST. If it doesn’t, I know the system is vulnerable and that package should be updated.
I also took advantage of Chef Client 12’s new reboot resource to reboot the server right away. It’s recommended that servers be rebooted once glibc is updated, since it is used by almost every program on the system, including the ones currently in memory. Obviously, rebooting right away isn’t desirable for everyone; you might want to wait until a maintenance window.
Here’s the complete code:
One thing I still don’t like about my solution is that it only applies to the RedHat Enterprise Linux systems I manage. What about other Linux variants, like Ubuntu? And wouldn’t it be nice if we knew, at all times, what packages and versions were installed on a system?
I decided to extend a community Ohai plugin that I found to do just that; you can find the source code here. Once this plugin has been installed by using resources in the Ohai cookbook as I previously described in the Shellshock blog post, you will have attributes in your Chef node object under node['linux']['packages']. Inspecting the elements node['linux']['packages']['glibc']['version'] and node['linux']['packages']['glibc']['release'] will indicate whether you need to upgrade glibc.
We’re currently in the midst of implementing Chef RFC 35, which defines a language for including controls within cookbooks. (The term arises from compliance in regulated industries, but you can also think of these as live acceptance tests a la minitest-handler, only better.) Once this feature is implemented, you’ll be able to define conditions like “what version of glibc should I be running?” using a ServerSpec-like syntax. That itself isn’t that interesting, but becomes very powerful once coupled with our commercial analytics product that allows you to filter, alert on, and notify people or systems about control violations.
You can try out an early implementation of controls by installing version 12.2.0-alpha of our Chef Client (curl -L https://www.chef.io/chef/install.sh | sudo bash -s -- -v 12.2.0.alpha.0)
As you can see, Chef’s flexible recipe language and easy-to-use plugin system for Ohai gives you a variety of ways to detect, correct, and report on security problems requiring attention in your infrastructure. Let’s hope, though, that there aren’t many more serious, widespread security vulnerabilities this year!