Blog Tags: 

CVE-2015-0235 GHOST: reboot or restart services

A remotely exploitable, 14 year old bug in glibc has reared its ugly head: CVE-2015-0235

Security updates have been pushed out automatically, courtesy of Debian (security tracker) to TurnKey 13 installations. TurnKey 12 installations that have enabled Squeeze LTS support have also received an update.

If you want to verify that your system is patched you can compile and run ghosttest.c

Running processes need to be restarted

Here's the catch, even after applying the security updates any running process (e.g., service) that links to libc is still potentially vulnerable until restarted. The best thing to do if possible is reboot your system through Webmin or the console:

# /sbin/reboot

The second best thing is to restart running services that link to libc.

I've created a helper script to make this easier: lsof-restart-services

# lsof-restart-services
Syntax: /usr/local/sbin/lsof-restart-services lsof-pattern
Restarts running Debian services that match lsof-pattern (e.g., libc)"

Environment variables:

    DRYRUN=y        If set, don't actually restart services, just echo

# DRYRUN=y lsof-restart-services libc
/etc/init.d/acpid restart
/etc/init.d/cron restart
/etc/init.d/ntp restart
/etc/init.d/rsyslog restart
/etc/init.d/shellinabox restart

# /usr/local/sbin/lsof-restart-services libc
/etc/init.d/acpid restart
[ ok ] Stopping ACPI services....
[....] Starting ACPI services...RTNETLINK1 answers: No such file or directory
acpid: error talking to the kernel via netlink
. ok
/etc/init.d/cron restart
[ ok ] Restarting periodic command scheduler: cron[....] Stopping periodic command scheduler: cron.
[ ok ] Starting periodic command scheduler: cron.
/etc/init.d/ntp restart
[ ok ] Stopping NTP server: ntpd.
[ ok ] Starting NTP server: ntpd.
/etc/init.d/rsyslog restart
[ ok ] Stopping enhanced syslogd: rsyslogd.
[ ok ] Starting enhanced syslogd: rsyslogd.
/etc/init.d/shellinabox restart

 

Mitigating factors

This looks relatively difficult to exploit.

From the Qualys Security Advisory

  • The gethostbyname*() functions are obsolete; with the advent of IPv6, recent applications use getaddrinfo() instead.
  • Many programs, especially SUID binaries reachable locally, use gethostbyname() if, and only if, a preliminary call to inet_aton() fails. However, a subsequent call must also succeed (the "inet-aton" requirement) in order to reach the overflow: this is impossible, and such programs are therefore safe.
  • Most of the other programs, especially servers reachable remotely, use gethostbyname() to perform forward-confirmed reverse DNS (FCrDNS, also known as full-circle reverse DNS) checks. These programs are generally safe, because the hostname passed to gethostbyname() has normally been pre-validated by DNS software:
  • "a string of labels each containing up to 63 8-bit octets, separated by dots, and with a maximum total of 255 octets." This makes it impossible to satisfy the "1-KB" requirement.
  • Actually, glibc's DNS resolver can produce hostnames of up to (almost) 1025 characters (in case of bit-string labels, and special or non-printable characters). But this introduces backslashes ('\') and makes it impossible to satisfy the "digits-and-dots" requirement.

You would effectively have to control the DNS server, or spoof its responses, to get the software to accept a suitable exploit.

Comments

Liraz Siri's picture

If it were a systematic issue we'd get a lot more complaints I suppose.
Liraz Siri's picture

Thanks David. I just added a link to that blog post to make it easier to find.
Liraz Siri's picture

Looks like there is something wrong with the reply handler I wrote.
Liraz Siri's picture

Just reboot. That's the easiest thing to do. New instances will be free of the issue as they install security updates on first boot. But you don't need to reinstall the system. Existing systems also auto-update. You just need to reboot (or restart the services manually).

Pages

Add new comment