GHOST glibc Linux Remote Code Execution Vulnerability / gethostbyname CVE-2015-0235

soulshepard

Verified User
Joined
Feb 7, 2008
Messages
133
It appears we have yet another sleepy crawly creepy bug lurking in the depths of our linux boxes..
A Gblic bug that was not identified as a security bug, perhaps a true y2k bug is effecting us now..
Possible exim.. and more.. in any case a remote execution possibility for many systems...

I guess it is time to emergency patch all the server again as soon as the patches come available.
As i read all distros are releasing / building patches for it.

source: http://www.openwall.com/lists/oss-security/2015/01/27/9
source: http://www.zdnet.com/article/critical-linux-security-hole-found/


--[ 1 - Summary ]-------------------------------------------------------------

During a code audit performed internally at Qualys, we discovered a
buffer overflow in the __nss_hostname_digits_dots() function of the GNU
C Library (glibc). This bug is reachable both locally and remotely via
the gethostbyname*() functions, so we decided to analyze it -- and its
impact -- thoroughly, and named this vulnerability "GHOST".

Our main conclusions are:

- Via gethostbyname() or gethostbyname2(), the overflowed buffer is
located in the heap. Via gethostbyname_r() or gethostbyname2_r(), the
overflowed buffer is caller-supplied (and may therefore be located in
the heap, stack, .data, .bss, etc; however, we have seen no such call
in practice).

- At most sizeof(char *) bytes can be overwritten (ie, 4 bytes on 32-bit
machines, and 8 bytes on 64-bit machines). Bytes can be overwritten
only with digits ('0'...'9'), dots ('.'), and a terminating null
character ('\0').

- Despite these limitations, arbitrary code execution can be achieved.
As a proof of concept, we developed a full-fledged remote exploit
against the Exim mail server, bypassing all existing protections
(ASLR, PIE, and NX) on both 32-bit and 64-bit machines. We will
publish our exploit as a Metasploit module in the near future.

- The first vulnerable version of the GNU C Library is glibc-2.2,
released on November 10, 2000.

- We identified a number of factors that mitigate the impact of this
bug. In particular, we discovered that it was fixed on May 21, 2013
(between the releases of glibc-2.17 and glibc-2.18). Unfortunately, it
was not recognized as a security threat; as a result, most stable and
long-term-support distributions were left exposed (and still are):
Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7,
Ubuntu 12.04, for example.

Read more...
Other sources :
https://threatpost.com/ghost-glibc-remote-code-execution-vulnerability-affects-all-linux-systems/110679
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235
 
Last edited:

tristan

Verified User
Joined
Feb 11, 2005
Messages
404
Location
The Netherlands
Interesting bit as well:

The Exim mail server is exploitable remotely if configured to perform
extra security checks on the HELO and EHLO commands ("helo_verify_hosts"
or "helo_try_verify_hosts" option, or "verify = helo" ACL); we developed
a reliable and fully-functional exploit that bypasses all existing
protections (ASLR, PIE, NX) on 32-bit and 64-bit machines.
 

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
13,853
Location
GMT +7.00
CentOS:

The exploit is fixed in glibc-2.12-1.149.el6

Update glibc


To mitigate the issue, please update to the latest version of glibc:
Code:
yum clean all && yum update "glibc*"
Version glibc-2.12-1.149.el6 and up is not affected, so be sure you are at this patch level. If your yum repository does not have this update yet, it may still be rsyncing, or yet to rsync.

https://www.centosblog.com/critical-glibc-remote-vulnerability-exploit-ghost-patch-glibc-now/

After glibc update you should restart all the services (which use the lib), or reboot a server.
 

soulshepard

Verified User
Joined
Feb 7, 2008
Messages
133
update instructions

Disclaimer: allways backup, check & test before you start updating or upgrading!, especially in production/hosting enviroments

Some patch hints:

CentOS

Selective update:
Code:
   yum clean all && yum update "glibc*"
   sudo reboot
Do all updates:
Code:
   yum update
   sudo reboot

Debian 7 / Ubuntu (older then 13.10) / Turnkey Linux

selective update:
Code:
   sudo apt-get update && apt-get -y install libc6
   sudo reboot
Do all updates:
Code:
  sudo apt-get update && sudo apt-get upgrade
  sudo reboot
Debian 6

If you do not use LTS support , then you first need to change the sources.list. To add the option to get new user contributed updates.

Code:
/etc/apt/sources.list
add the following:
Code:
deb [url]http://security.debian.org/[/url] squeeze/updates main contrib non-free
deb-src [url]http://security.debian.org/[/url] squeeze/updates main contrib non-free
then you can use:

selective update:
Code:
apt-get update && apt-get -y install libc6
sudo reboot
complete update:
Code:
sudo apt-get update && sudo apt-get upgrade
sudo reboot
Caution: i have not tested Debian 6, but the above would enable the update.
As allways be careful and backup / test things before you start this.

And while you are busy with this then you can also check if the shellshock patch gas been applied .. for the people who "forgot"

Centos:

selective update:
Code:
sudo yum update bash -y
Debian:

selective update:
Code:
sudo apt-get update && sudo apt-get install --only-upgrade bash
check:
Code:
env 'VAR=() { :;}; echo Bash is vulnerable!' 'FUNCTION()=() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"
 
Last edited:

soulshepard

Verified User
Joined
Feb 7, 2008
Messages
133
Last edited:

soulshepard

Verified User
Joined
Feb 7, 2008
Messages
133
also another nice post with explenation:

source: http://www.zdnet.com/article/critical-linux-security-hole-found/

Code:
To exploit this vulnerability, all an attacker needs to do is trigger a buffer overflow by using an invalid hostname argument to an application that performs a DNS resolution. This vulnerability then enables a remote attacker to execute arbitrary code with the permissions of the user running DNS. In short, once an attacker has exploited GHOST they may be capable of taking over the system.
Code:
My advice to you is to now, not later today, now, update your Linux system as soon as possible. After patching it, you should then reboot the system. I know for Linux it's rarely needed to reboot, but since gethostbyname is called on by so many core processes, such as auditd, dbus-daem, dhclient, init, master, mysqld, rsyslogd, sshd, udevd, and xinetd, you want to make absolutely sure that all your system's running programs are using the patched code.
 

soulshepard

Verified User
Joined
Feb 7, 2008
Messages
133
source: http://seclists.org/oss-sec/2015/q1/283

As i read the following daemons are not vulnerable and were tested by Qualys.
As it appears Exim is the most affected.

Code:
Here is a list of potential targets that we investigated (they all call
gethostbyname, one way or another), but to the best of our knowledge,
the buffer overflow cannot be triggered in any of them:

apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql,
nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd,
pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers,
vsftpd, xinetd.

That being said, we believe it would be interesting if other people
could have a look, just in case we missed something.
 

ccto

Verified User
Joined
Feb 24, 2005
Messages
137
Location
Hong Kong
a small question -

Do we need to run custombuild recompile apache, exim, dovecot, etc with the latest glibc library?

or simply yum update is sufficient enough?

Sorry, I have little knowledge on the compiler and library.

Thank you very much.
Regards
 

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
13,853
Location
GMT +7.00
According to this:

Code:
lsof | grep libc
you do *not* require to rebuild software after the glibc update.
 

Arieh

Verified User
Joined
May 27, 2008
Messages
1,200
Location
The Netherlands
a small question -

Do we need to run custombuild recompile apache, exim, dovecot, etc with the latest glibc library?

or simply yum update is sufficient enough?

Sorry, I have little knowledge on the compiler and library.

Thank you very much.
Regards
No but you do need to restart all services, or simply the server as mentioned a few times in the thread already.

The reason for this is that services load in the library when they start, if you change/update the lib afterwards it doesn't affect the running services.
 

ditto

Verified User
Joined
Apr 27, 2009
Messages
2,453
@ccto, you should restart all services that uses glibc after you have run yum update, or you could reboot the server to make sure all services are restarted.

Also follow the discussion at webhostingtalk.com at http://www.webhostingtalk.com/showthread.php?t=1450048

If I was you, I would just run:
Code:
service exim restart
And then wait for the new kernel before you reboot, so you don't have to reboot two times in short periode. It was released a new kernel to RedHat yesterday, but it is not yet available in CentOS: https://rhn.redhat.com/errata/RHSA-2015-0087.html Should be available in CentOS shortly.

It is most important to restart exim, read more in the announcement from exim maillist here: https://lists.exim.org/lurker/message/20150127.200135.056f32f2.en.html
 

jackc

Verified User
Joined
Jan 19, 2007
Messages
347
It is most important to restart exim, read more in the announcement from exim maillist here: https://lists.exim.org/lurker/message/20150127.200135.056f32f2.en.html
To protect Exim against the HELO/EHLO attack vector, do *not* set either
of these in the main configuration:

helo_verify_hosts
helo_try_verify_hosts


and do *not* use the following in any ACLs:

verify = helo
I believe by default, exim in directadmin install doesn't have those set. Right?
 

zEitEr

Super Moderator
Joined
Apr 11, 2005
Messages
13,853
Location
GMT +7.00
Please check Debian 6 section here: #5

and check this:

Code:
[COLOR=#000000]wget https://gist.githubusercontent.com/koelling/ef9b2b9d0be6d6dbab63/raw/de1730049198c64eaf8f8ab015a3c8b23b63fd34/gistfile1.c[/COLOR]
gcc gistfile1.c -o CVE-2015-0235

./CVE-2015-0235
 
Top