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

Dream Cutter's picture

When pushed to my server (TKL 13 Drupal) the next morning my sites were down and a black screen on the server (glow, no text).  Restarted and all is fine.  I checked email and saw thuis was pushed.  Hardware glitch is a coincidence?

Liraz Siri's picture

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

It happened again several times yesterday.  It appears to be a powersupply failing and so its a cooincidense

Ed Carp's picture

"TurnKey 12 installations that have enabled Squeeze LTS support have also received an update."

How can I enable this?

David A. Kidd's picture

Liraz Siri's picture

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

Thank you!

 

By the way, I received this error when trying to respond vial email:

 

This is the mail system at host mail.turnkeylinux.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<reply-handler@turnkeylinux.org>: Command died with status 1: "
    PATH=$HOME/bin:$PATH mailpipe-reply --auth-sender=$HOME/secret --bodyfilter
    rst2html --mailback-error 'ssh www-data@eta
    /usr/share/mailpipe/contrib/drupal_post_comment.php'". Command output:
    /usr/bin/mailpipe-reply:57: DeprecationWarning: the sha module is
    deprecated; use the hashlib module instead   import sha
    /usr/lib/mailpipe/action.py:6: DeprecationWarning: The popen2 module is
    deprecated.  Use the subprocess module.   from popen2 import Popen4
Liraz Siri's picture

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

What is the best approach:

stop and restart my instance?  

terminate and start a new instance?  I'm thinking a new instance will be free of this issue, is that correct?

or does the above apply?

Sorry if these are simple questions, new at this...

 

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