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, 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.
They're only attacking host-lookup, so you just have to worry about people who can connect to your service and are able to control name server response. This means your network services that are internet-accessible. Everything else can wait for a maintenance window for the reboot.
It doesn't have to be internet accessible, AFAIK. If an attacker can get something to do arbitrary DNS lookups, I think it can be attacked. For instance, monitoring/log correlation software might be vulnerable.
This is a good idea in general. However, every version of ssh that I could test (going back to Ubuntu 8.04) uses getaddrinfo() rather than gethostbyname() and is therefore safe.
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
That limit is set somewhere in the kernel but it's not clear if lsof is just setting that as a maximum internally or probing somewhere - I used strace -etrace='!close' lsof +c 64 but I couldn't see anything related to the limit.
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.
Yeah, that's a good point, and definitely worth mentioning, but obviously rebooting isn't going to help in that case either. The parent was asking about how they would know if they need to reboot or not.
You're testing what happens when you delete a file for which an open file descriptor exists. On Linux, a shared library will normally be memory-mapped but will not have a corresponding file descriptor. So lsof will show DEL, not (deleted).
I wouldn't normally nitpick about something like this, but if people follow your advice they might incorrectly think they don't need to reboot.
