21–30 of 254 posts
Earlier quoted context omitted.
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.
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…
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.
sudo lsof | grep lib | grep DEL
You can then either reload those processes manually, or just bounce the box if that's easier.
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?
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?
From https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235 "A heap-based buffer overflow was found in __nss_hostname_digits_dots(), which is used by the gethostbyname() and gethostbyname2() glibc function call. A remote attacker could use this flaw to execute arbitary code with the permissions of the user running the application."
Obligatory git link for the curious: https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/digits_... . Note that this is a HEAD link, so if there are changes after I post this they should appear. I don't claim to have spotted the suspicious code (it's not ... super-accessible), just wanted to provide a link to the file in question.
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…
~# netstat -lnp | grep -e "\(tcp.*LISTEN\|udp\)" | cut -d / -f 2- | sort -u
cupsd
dnsmasq
httpd
nmbd
ntpd
qemu-kvm
rpc.portmap
rpc.statd
sendmail: acce
smbd
ssh
sshdWhen 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.
This is the original report: https://sourceware.org/bugzilla/show_bug.cgi?id=15014 Upstream patch: https://sourceware.org/git/?p=glibc.git;a=commit;h=d5dd6189d... Full diff: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d5dd6... Red Hat bug: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235 Debian bug: https://bugs.debian.org/776391 Great write-up from the discoverer (Qualys): http://www.openwall.com…
/edit: a second note about Go; even without the native resolver, Go uses getaddrinfo, not gethostbyname*, and it's not vulnerable.