Researchers have discovered and announced a major flaw in one of the building blocks on Linux operating system – the GNU C Library. The vulnerability has been reported as CVE-2015-7547 and was disclosed on Tuesday, February 16, 2016. The vulnerability is in function getaddrinfo() that performs domain-name (DNS) lookups.
The vulnerability allows remote exploitation. Proof of concept has been published and exploits using the vulnerability have started to emerge.
Who is vulnerable
Being a core OS function, glibc is used by thousands of higher level software, including programming languages such as PHP or Python. All versions of glibc newer than 2.9 are vulnerable as the vulnerability has been introduced in 2008. Widely used server Linux distributions such as Redhat Enterprise Linux and Debian are vulnerable as well.
At this date, most Linux distribution vendors have released updates, but the simple fact that you update the operating system is not enough to mitigate the issue, because:
- You might use third-party software that is statically linked with glibc. While this is a bad practice, it is not very uncommon.
- Daemons dynamically linking glibc must be restarted in order to load the new library in memory.
That’s why it is strongly recommended to restart the OS after you perform this update.
To avoid the reboot (at least until the next scheduled update) and to make absolutely sure that no exploitation is possible even if your system runs vulnerable software maintained by third-party vendors that did not release a patch, we recommend the following approach:
1) Download and execute the firewall:
curl https://raw.githubusercontent.com/4psa/voipnowpatches/master/CVE-2015-7547-fix.sh -o CVE-2015-7547-fix.sh
This shell script will add to firewall rules that DROP DNS packages larger than 512 bytes UDP and 1024 bytes TCP, which will introduce immediate protection against the vulnerability with no functionality impact.
This is a generic script designed to protect any Linux system. It has been tested on RHEL, CentOS, CloudLinux, Debian, Ubuntu and Virtuozzo. We make no warranties, if you discover any issue, we welcome pull requests.
Update 1: We removed FORWARD rules from the script. The rules were initially added for machines that host containers to protect them all, but this is not the best approach – you cannot protect them all so easily. It’s highly suggested not to use this script on machines you run a DNS server on.
2) Update your operating system using the normal procedure with “yum update” or any other distro specific tool such as apt-get.
3) Restart the OS in your next scheduled maintenance window.
Feb 16, 2016 ~17:00 GMT
We became aware of the vulnerability.
Feb 16, 2016 17:30 GMT
We started to investigate our software (both our own code and repositories shipped as dependencies) to determine where and how we are affected by the issue.
Feb 17, 2016 10:50 GMT
All our systems and customer systems hosted by us (VoipNow OnDemand, DNS Manager OnDemand and Hubgets) are protected against the vulnerability.
Feb 17, 2016 12:10 GMT
We produced a hotfix mitigation script and notified our customers to apply it immediately on their systems.
Feb, 17 2016 12:15 GMT
We produced a generic version of the firewall hotfix and published it openly for download.
As of February 17, 2016 12:00 GMT we have not located specific vulnerabilities in our shipped software, so technically the vulnerability should be fixed with an OS update and reboot. But as the investigation has not been fully completed, we highly recommend to all our customers to apply the firewall protection script described above.
You can post comments in this post.
Thanks for the script. It looks like the size limit is set to 1024 in the script for both UDP and TCP, is that an error?
Also, couldn’t this break some stuff like DNSSEC and EDNS? It seems UDP DNS packets can be larger than 512 bytes now if both the client and server support it.
Matt 7 years ago
You are correct. We updated the script, initially we added some FORWARD rules for containers (so you can run the script on a hardware node), but it will break machines that run DNS.
Blog wizard 7 years ago
You have to be aware, by implementing this limit – dig any $domain might fail since you prevent packets from being made, so it might have an impact. e.g. I have a domain where the total message size of the DNS response is 493 bytes, but since you also have to take the overhead into account this will cause it to fail. Doing the same dig but enforcing tcp using +tcp it will make the call succeed.
Lucas Rolff 7 years ago
Post A Reply