Live data from Hacker News

CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

openwall.com

121–130 of 254 posts

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#121
post #41

Earlier quoted context omitted.

That's a great writeup. It will be really interesting to see how they achieve remote code execution under those limitations. Also surprising to note that we've been vulnerable since November 2000.

They give it away (which I find moderately not nice of them) by saying they used Exim (the mail server) in their POC.

The default exim config seems to not be vulnerable.

I checked the configs on two of my systems, one default, and one heavily customized, neither had the helo verification turned on.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#122
According to this update: http://www.openwall.com/lists/oss-security/2015/01/27/18

The Qualys guys were unable to find any issues with sshd and tcp_wrappers. I imagine I'm not the only one that has /etc/hosts.deny setup to reject all but some IPs, but according to Qualys tests this issue cannot be triggered via someone with exploitable RDNS. As far as they know -- of course you should upgrade when you can.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#123

When the patches are available, you need to update, and likely reboot. Mattias Geniar talks about using the following command to find processes depending on libc, any of which could be running the vulnerable code, these are core processes that you probably cannot just cycle without a reboot [1]. For me the listing looks something like this: agetty, auditd, dbus-daem, dhclient, init, master, mysqld, rsyslogd, sshd, ud…

Just remember that by default lsof prints only first 9 characters of process name, so processes with long names will be cut. You can change how much initial characters lsof prints with +c command, but often kernel does not supply full names for lsof, example limit in my box is 15 characters

>lsof +c 64

lsof: +c 64 > what system provides (15)

So

lsof +c 15 is maximum

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#124

Details on this one appear to be quite sparse - under what use cases would a remote user be able to craft invalid IP addresses?

I'm curious on this one too. How exactly can this be exploited remotely? SSH trickery? If a PHP script is doing geolookups or resolving of user's IP's to hosts?

How do I make my hosts secure?

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#125
post #51

Dumb question perhaps, but is there a command line command I can run to test before and after that this patch has been applied successfully?

The Qualys link (elsewhere on this page) contains sample code to test if you are vulnerable. Also, you can check your glibc version with this tiny code: #include #include int main (void) { puts (gnu_get_libc_version ()); return 0; } (taken from a forum that I've since closed the page on, sorry for lack of attribution) = 2.18 is safe. ldd --version might also do the trick.

Thanks, super helpful!

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#127
post #55

Earlier quoted context omitted.

It is nice if they can count. However instead of sending them back to kindergarten, it might make sense to find a compiler/language/framework that would make inability to count not result in easy remote exploits.

So remove the ability to use pointers to directly access memory. Then you're only left with all of the other security vulnerabilities found in every such language.

It would still be an improvement.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#128

Glancing over the patch, this appears to be the crucial part: size_needed = (sizeof (*host_addr) - + sizeof (*h_addr_ptrs) + strlen (name) + 1); + + sizeof (*h_addr_ptrs) + + sizeof (*h_alias_ptr) + strlen (name) + 1); Doesn't it seem disappointing that some programmers, for whatever reason, just can't seem to count correctly?

I find it pretty funny how no matter how many times we're shown that unsafe languages blow up on all sorts of code by all sorts of programmers, anyone would still try to defend the language.

FFS in this case they even found the bug and fixed it, but didn't notice how it could be a vulnerability. So even with eyes directly on issues, we (human programmers excluding djb) can't seem to get it right.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#130

Earlier quoted context omitted.

There's also a rare chance that a program is statically linked, in which case upgrading glibc won't help, the program would need to be recompiled.

It is nearly impossible to statically link glibc.

... with nss-modules being a major culprit, ironically... (on which gethostbyname relies greatly)...
Post reply on HN