Is this serious? Does this mean if I have an app, Java, PHP or whatever, which eventually calls glibc's gethostbyname gethostbyaddr, my machine is owned? That somebody could just craft a special hostname or ip address to lookup? So all those websites where you enter hostname o IP address to lookup something like whois info or ping other machines, could be owned?
CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
11–20 of 254 posts
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#12I'm glad the moderator removed GHOST from the subject line. CVEs don't need a media friendly handle. Edit: Its back again. Booooo.
We disagree on that, especially when they're widespread (and you don't get much more widespread than glibc) and "drop everything and patch"-level severity. Having a shorthand to refer to the bug makes it more easy (and therefore more likely) that it will get referenced and discussed.
I think the parent comment was sarcastic.
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#13Is this serious? Does this mean if I have an app, Java, PHP or whatever, which eventually calls glibc's gethostbyname gethostbyaddr, my machine is owned? That somebody could just craft a special hostname or ip address to lookup? So all those websites where you enter hostname o IP address to lookup something like whois info or ping other machines, could be owned?
If it affects gethostbyaddr that'd be really bad - there are a lot of applications that automatically look up reverse DNS on a connection.
Mail servers in particular generally make it pretty easy to trigger both forward and reverse lookups.
The test case seems to have it looking up an ip address as if it were a name, but it's using the reentrant version of the function - maybe only those are affected?
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#14When 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, udevd, xinetd. Many of these deal with hostnames, so I would want to be sure everything is clean, and the best option is likely a reboot.
lsof | grep libc | awk '{print $1}' | sort | uniq
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#15I'm glad the moderator removed GHOST from the subject line. CVEs don't need a media friendly handle. Edit: Its back again. Booooo.
plus the original email was sent from a PR agency.
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#16I'm glad the moderator removed GHOST from the subject line. CVEs don't need a media friendly handle. Edit: Its back again. Booooo.
I think it's okay to assign a media name to vulnerabilities, but only if the vulnerability is truly severe enough (easy to exploit and serious magnitude) to warrant it. Otherwise it's just an attempt at marketing and PR.
In this case, it looks the name is probably not warranted.
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#17Details on this one appear to be quite sparse - under what use cases would a remote user be able to craft invalid IP addresses?
It seems it was made public by accident, so it is not totally surprising that information is sparse :(
Given that I recently received a Debian Security Advisory which specifically addressed this CVE, I don't think it was accidental at all.
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#18When 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…
For immediate actions, maybe also set 'UseDNS no' in /etc/ssh/sshd_config and restart any public-facing ssh servers.
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#19When 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…
Thank you, it's not always clear when a reboot is needed after an update. I do it with kernel updates but wouldn't have in this case until I read your comment and ran the command to check.
If would be nice if package managers would let us know when this is necessary, I expect that might be a hard thing to get right though.
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#20Debian security advisory: http://www.securityfocus.com/archive/1/534554/30/0/threaded