GHOST itself is a Heap Overflow in the name resolution function of the Glibc.

Technically GHOST is a heap overflow, which is a very common bug in C programming. C is inherently prone to these kinds of memory corruption errors and there are essentially two things here to move forwards: Improve the use of exploit mitigation techniques like ASLR and create new ones (levee is an interesting project, watch this 31C3 talk). And if possible move away from C altogether and develop core components in memory safe languages (I have high hopes for the Mozilla Servo project, watch this linux.conf.au talk).

GHOST was discovered three times

But the thing I want to elaborate here is something different about GHOST: It turns out that it has been discovered independently three times. It was already fixed in 2013 in the Glibc Code itself. The commit message didn’t indicate that it was a security vulnerability. Then in early 2014 developers at Google found it again using Address Sanitizer (which – by the way – tells you that all software developers should use Address Sanitizer more often to test their software). Google fixed it in Chrome OS and explicitly called it an overflow and a vulnerability. And then recently Qualys found it again and made it public.

Now you may wonder why a vulnerability fixed in 2013 made headlines in 2015. The reason is that it widely wasn’t fixed because it wasn’t publicly known that it was serious. I don’t think there was any malicious intent. The original Glibc fix was probably done without anyone noticing that it is serious and the Google devs may have thought that the fix is already public, so they don’t need to make any noise about it. But we can clearly see that something doesn’t work here. Which brings us to a discussion how the Linux and free software world in general and vulnerability management in particular work.

The “Never touch a running system” principle

Quite early when I came in contact with computers I heard the phrase “Never touch a running system”. This may have been a reasonable approach to IT systems back then when computers usually weren’t connected to any networks and when remote exploits weren’t a thing, but it certainly isn’t a good idea today in a world where almost every computer is part of the Internet. Because once new security vulnerabilities become public you should change your system and fix them. However that doesn’t change the fact that many people still operate like that.

A number of Linux distributions provide “stable” or “Long Time Support” versions.

These systems are delivered with an implicit promise: We will take care of security and if you update regularly you’ll have a system that doesn’t change much, but that will be secure against know threats. Now the interesting question is: How well do these systems deliver on that promise and how hard is that?

Vulnerability management is chaotic and fragile

LTS and stable distributions are there for a reason

The big question is of course what to do about it. OpenBSD developer Ted Unangst wrote a blog post yesterday titled Long term support considered harmful, I suggest you read it. He argues that we should get rid of long term support completely and urge users to upgrade more often. OpenBSD has a 6 month release cycle and supports two releases, so one version gets supported for one year.

Given what I wrote before you may think that I agree with him, but I don’t. While I personally always avoided to use too old systems – I ‘m usually using Gentoo which doesn’t have any snapshot releases at all and does rolling releases – I can see the value in long term support releases. There are a lot of systems out there – connected to the Internet – that are never updated. Taking away the option to install systems and let them run with relatively little maintenance overhead over several years will probably result in more systems never receiving any security updates. With all its imperfectness running a Debian Squeeze with the latest updates is certainly better than running an operating system from 2011 that stopped getting security fixes in 2012.

Improving the information flow

I don’t think there is a silver bullet solution, but I think there are things we can do to improve the situation. What could be done is to coordinate and share the work. Debian, Red Hat and other distributions with stable/LTS versions could agree that their next versions are based on a specific Glibc version and they collaboratively work on providing patch sets to fix all the vulnerabilities in it. This already somehow happens with upstream projects providing long term support versions, the Linux kernel does that for example. Doing that at scale would require vast organizational changes in the Linux distributions. They would have to agree on a roughly common timescale to start their stable versions.

Cisco has put forward at least a partial response to 2015′s first branded bug, GHOST, saying that in The Borg’s world, the glibc vulnerability is probably of relatively low severity.

That would, at least, explain why it’s not being hunted with quite the urgency of something like Heartbleed in 2014: right now, Cisco’s advisory states that it hasn’t confirmed the vulnerability status of any individual products.

“The superseding function is getaddrinfo() which … is not affected by this buffer overflow”.

Cisco says its intrusion prevention system and next generation firewall both include rules that would block attempts to exploit GHOST, and the company will issue an advisory if any of its products turn out to be vulnerable and need patching.

However, researchers from website security research firm Sucuri said Wednesday that they have good reasons to believe the flaw can also be exploited through Web applications written in PHP that use gethostbyname() function wrappers. This has the potentially to significantly expand the attack vectors.

One clear example of such a PHP application is WordPress, which uses a function called wp_http_validate_url() to validate the URLs of pingback posts.

“It does so by using gethostbyname(), so an attacker could leverage this vector to insert a malicious URL that would trigger a buffer overflow bug, server-side, potentially allowing him to gain privileges on the server,” Sucuri senior vulnerability researcher Marc-Alexandre Montpas said in a blog post.

Then Thursday, security researchers from Trustwave SpiderLabs created a proof-of-concept script to trigger the glibc buffer overflow though the WordPress pingback feature.

“This PoC allows users to remotely verify if a target web server is vulnerable to the CVE however it does not demonstrate exploitability,” they said in a blog post.

GHOST gethostbyname() heap overflow in glibc (CVE-2015-0235)
http://blog.spiderlabs.com/2015/01/ghost-gethostbyname-heap-overflow-in-glibc-cve-2015-0235.html

Recommendations
Install glibc Patches
And don’t forget to reboot!
Disable XML-RPC

It is possible to disable the XML-RPC process altogether if you do not want to use it. There are even plugins that will disable it.

Disable Pingback Requests
You may also disable the pingback feature by adding the following to your functions.php file

WAF Protections
By using a WAF, you can identify initial pingback XML requests on your WordPress site and look for attacks.

Monitor Your Logs
When attackers are attempting to exploit this vulnerability against your web servers, there will most likely be error messages (segmentation faults, etc…) that will indicate a problem. Organizations should be vigilant in monitoring their logs and following up on an anomalous errors.

Update as soon as possible!

This is a very critical vulnerability and should be treated as such. If you have a dedicated server (or VPS) running Linux, you have to make sure you update it right away. We know for a fact that Centos/RHEL/Fedora 5,6,7 as vulnerable, as well as some Ubuntu versions.

Hackers could exploit the Ghost Linux bug using WordPress-based attacks, according to researchers at Trustwave, which has produced a proof-of-concept cyber attack to prove its claim.

Ziv Mador, vice president of security research at Trustwave, told V3 that the proof-of-concept will work on all vulnerable Linux systems, and showcases how hackers could exploit Ghost.

“The proof-of-concept code can be used to check whether a remote web server is vulnerable to Ghost. It works by sending an XML request to the XML-RPC Pingback functionality of WordPress which includes a long URL,” he explained.

“The code works on patched and unpatched versions but they will respond in a different way thus allowing the researcher or administrator to determine whether the server is patched or not.”

t is currently unclear whether Ghost is being actively exploited, although Qualys believes that hackers could bypass many traditional defences.

“During our testing, we developed a proof-of-concept in which we send a specially created email to a mail server and can get a remote shell to the Linux machine,” read the advisory.

“This bypasses all existing protections (like ASLR, PIE and NX) on both 32-bit and 64-bit systems.”

I don’t buy the OpenSSH “mitigation” linked to – Reverse DNS in OpenSSH or OpenSSH+libwrap is not exploitable.)
Because of common programming idioms, and the very specific code paths to the vulnerable code, many programs are not vulnerable. To be clear, there is a problem affecting a handful of DNS related functions in glibc(<2.18), and DNS is an excellent way to get attacker controlled data into a system, though it's not a great way to get arbitrary data in. But, unlike some recent high profile issues, simply using the library or using those functions does not automatically make a program vulnerable.
glibc has had that function since 1996 (pre v2.0), so gethostbyname() won't be called by OpenSSH.
In the general case, since conforming DNS data cannot contain problematic long/malformed IP addresses, reverse look up and forward/reverse checks are not an attack vector. Where hostnames/dotted-quad addresses are part of a higher protocol (e.g. the SMTP EHLO name, as used exploiting Exim) then you might have something. For OpenSSH this would suggest host names in port-forwarding. Close, but no cigar, even if OpenSSH did use gethostbyname() directly

A bug is haunting Linux systems.

The Ghost vulnerability recently revealed by researchers at Qualys has triggered comparisons to Shellshock, but some experts say that both the impact and how organizations should approach patching it is different.

“Applying a patch to bash and rolling out a newer version to me seems a lot easier,” said Jon Passki, lead security researcher at Coverity. “None of its dependencies are touched, so the fix can be very specific. As a sysadmin or someone in security operations, I’d rather have Shellshock than Ghost.”

Ghost is a buffer overflow issue in the Linux glibc library. If the bug is exploited, it could enable an attacker to take control of a targeted system.

“Glibc (libc) is a core library for many packages and for the host operating system,”

he short of it is upgrading from one version of glibc to another isn’t possible until the main operating system is upgraded. Then you get into third party packages. They often write and compile against certain versions of libc. Again, they’re in the same boat. For example, maybe there’s a bug in libc that prevents their application from working, so they’ll compile to an older version

“Libc might backport the fix because of all the aforementioned issues,” he added. “That would still require, in some cases, applications to be recompiled with the now patched backported libc…So there will be a lag in when those new versions are available.”

Patching glibc is a little different than a library like OpenSSL due to kernel and build tool dependencies

According to Qualys, the first vulnerable version of the GNU C Library affected by this is glibc-2.2, which was released on Nov. 10, 2000. There are a number of factors that mitigate the bug however; for example, the issue was actually fixed on May 21, 2013, between the releases of glibc-2.17 and glibc-2.18. However, most stable and long-term-support distributions were left exposed including Debian 7 (wheezy), Red Hat Enterprise Linux 6 and 7, CentOS 6 and 7 and Ubuntu 12.04.

The release of a fix in 2013 means that many newer Linux operating systems were never at risk

“Secondly, not all applications are at equal risk,” Kinger added. “Exploitation is very difficult as an attacker only has a small amount of initial exploit code that can be used: 4 or 8 bytes (depending on whether the system is a 32- or 64-bit system). Additional code must be written to an address referenced by a pointer which the attacker can modify. As a result, many apps are not at risk. So far, we are not aware of any potential web attack vectors, which reduces the attack surface considerably.”

The GHOST.c utility included in the original advisory can quickly tell you whether or not the local glibc has been patched, said Moore.

Qualys Security Advisory CVE-2015-0235
GHOST: glibc gethostbyname buffer overflow
https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt

procmail (a SUID-root and SGID-mail binary) is vulnerable through its
“comsat/biff” feature:

Conclusion: more than 3 dots is impossible,
and neither ping nor arping is vulnerable.

The Exim mail server is exploitable remotely if configured to perform
extra security checks on the HELO and EHLO commands

pppd (yet another SUID-root binary) calls gethostbyname() if a
preliminary call to inet_addr() (a simple wrapper around inet_aton())
fails. “The inet_addr() function converts the Internet host address cp
from IPv4 numbers-and-dots notation into binary data in network byte
order. If the input is invalid, INADDR_NONE (usually -1) is returned.
Use of this function is problematic because -1 is a valid address
(255.255.255.255).” A failure for inet_addr(), but a success for
inet_aton(), and consequently a path to the buffer overflow.

“To be clear, this is NOT the end of the Internet as we know it, nor is it another Heartbleed. In a general sense, it’s not likely to be an easy bug to exploit. One easily-exploitable case identified so far is the Exim mail server. An attacker could abuse this vulnerability to execute arbitrary commands on an unpatched server.”

“Still, it could potentially be nasty if exploited so we strongly recommend immediate patching and rebooting. Without a reboot, services using the old library will not be restarted,” Moore concluded.

Source: http://www.theregister.co.uk/2015/01/28/ghost_linux_megavuln_analysis/