5 ms·

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 lib

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. lsof | grep libc | awk '{print $1}' | sort | uniq [1] http://ma.ttias.be/critical-glibc-update-cve-2015-0235-gethostbyname-calls/ http://ma.ttias.be/critical-glibc-update-cve-2015-0235-getho...

contingencies 12y ago
For immediate actions, maybe also set 'UseDNS no' in /etc/ssh/sshd_config and restart any public-facing ssh servers.
- beagle3 12y ago
  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.
  - beagle3 12y ago
    ... or not necessarily safe, as people here claim that getaddrinfo() uses gethostbyname() under the covers. "UseDNS no" in your sshd_config is a good idea in general.
michaelx386 12y ago
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.
- JshWright 12y ago
  You can check to see if any running process are using any stale libraries pretty easily: sudo lsof | grep lib | grep DEL You can then either reload those processes manually, or just bounce the box if that's easier.
  - deleted 12y ago
    [deleted]
    - teraflop 12y ago
      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.
    - nkurz 12y ago
      You can see that the removed file gets a (deleted) in the 'NAME' column but not DEL in the 'TYPE'. Maybe you have a cut-and-paste error? The before and after look the same to me, no "(deleted)" to be seen.
      - danielweber 12y ago
        Use contrl-F to search, it got clipped off the right-hand side by HN's raw-mode display.
  - gtrubetskoy 12y ago
    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.
    - JshWright 12y ago
      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.
peterwwillis 12y ago
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. ~# 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 sshd
- correxion 12y ago
  sudo netstat -lnp | awk -F/ '/LISTEN /{print $2}'
- jerematasno 12y ago
  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.
  - NickNameNick 12y ago
    If you have backend systems parsing XML, then an XXE[1] attack could trigger a DNS lookup, for example. [1]https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing https://www.owasp.org/index.php/XML_External_Entity_%28XXE%2...
    - sarciszewski 12y ago
      Ooh, that could lead to some very interesting attack vectors. :D
stplsd 12y ago
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
- voltagex_ 12y ago
  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.
correxion 12y ago
lsof | awk '/libc/{print $1 | "sort -u" }' you're welcome

contingencies 12y ago

For immediate actions, maybe also set 'UseDNS no' in /etc/ssh/sshd_config and restart any public-facing ssh servers.

beagle3 12y ago
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.
- beagle3 12y ago
  ... or not necessarily safe, as people here claim that getaddrinfo() uses gethostbyname() under the covers. "UseDNS no" in your sshd_config is a good idea in general.

michaelx386 12y ago

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.

JshWright 12y ago
You can check to see if any running process are using any stale libraries pretty easily: sudo lsof | grep lib | grep DEL You can then either reload those processes manually, or just bounce the box if that's easier.
- deleted 12y ago
  [deleted]
  - teraflop 12y ago
    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.
  - nkurz 12y ago
    You can see that the removed file gets a (deleted) in the 'NAME' column but not DEL in the 'TYPE'. Maybe you have a cut-and-paste error? The before and after look the same to me, no "(deleted)" to be seen.
    - danielweber 12y ago
      Use contrl-F to search, it got clipped off the right-hand side by HN's raw-mode display.
- gtrubetskoy 12y ago
  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.
  - JshWright 12y ago
    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.

peterwwillis 12y ago

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. ~# 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 sshd

correxion 12y ago
sudo netstat -lnp | awk -F/ '/LISTEN /{print $2}'
jerematasno 12y ago
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.
- NickNameNick 12y ago
  If you have backend systems parsing XML, then an XXE[1] attack could trigger a DNS lookup, for example. [1]https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing https://www.owasp.org/index.php/XML_External_Entity_%28XXE%2...
  - sarciszewski 12y ago
    Ooh, that could lead to some very interesting attack vectors. :D

stplsd 12y ago

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

voltagex_ 12y ago
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.

correxion 12y ago

lsof | awk '/libc/{print $1 | "sort -u" }' you're welcome