Critical Vulnerability in Linux glibc (CVE-2015-7547)

3. Are statically-linked binaries affected by this flaw?
Yes they are. All binaries which are statically-linked against glibc, will need to be re-compiled with the new library.


So after glibc upgrade and a server reboot we need to re-build all the software on the server:

Code:
cd /usr/local/directadmin/custombuild
./build all d

Correct?
 
A ./build all d? Pfff.. I hope not.

Why do you need a server reboot after glibc update? I thought this was only necessary after a kernel update.
 
Reboot is not required but desirable.


After the update is applied you need to reboot the system or restart all affected services:

Because this vulnerability affects a large amount of applications on the system, the safest and recommended way to assure every application uses the updated glibc packages is to restart the system.

https://access.redhat.com/articles/2161461

PHP, cURL:

Code:
# php -i | grep glibc
iconv implementation => glibc

Exim? Dovecot? Apache/nginx? PureFTP/ProFTPd?

... the vulnerability extends to an almost incomprehensibly large body of software, including virtually all distributions of Linux; the Python, PHP, and Ruby on Rails programming languages; and many other things that uses Linux code to look up the numerical IP address of an Internet domain.

http://arstechnica.com/security/201...zzying-number-of-apps-and-devices-vulnerable/
 
Thank you Zeiter, I will reboot this night then. Pity this update was not available yet last night when I did the kernel and bind updates and rebooted all servers for the kernl. ;)
How about the "build all d", not neccessary then?
 
OK, here is what I've figured out:

Every software which uses getaddrinfo() (i.e.do a network address lookup) and is statically linked against glibc needs to be rebuilt.
Thus there is probably no need to rebuild software with custombuild:

Code:
[B]/usr/sbin/dovecot[/B]: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
[B]/usr/sbin/exim[/B]: setuid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
[B]/usr/sbin/httpd[/B]: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
[B]/usr/sbin/mysqld[/B]: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
[B]/usr/sbin/named[/B]: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
[B]/usr/sbin/proftpd[/B]: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
[B]/usr/sbin/sshd[/B]: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
[B]/usr/local/sbin/nginx[/B]: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
[B]/usr/local/bin/freshclam[/B]: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
[B]/usr/local/sbin/clamd[/B]: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
[B]/usr/local/php56/bin/php56:[/B] ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
[B]/usr/local/bin/curl[/B]: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

I hope somebody else could confirm that.
 
Correct, those are all dynamic, so a restart of the mentioned services should be enough.

But for a few OS's, DA itself is static, so you'd need to grab a fresh copy (I've already updated glibc on all the build boxes).
Can check with:
Code:
ldd /usr/local/directadmin/directadmin
Pre-release binaries have all the updates already too.
But, as for any major library update, I high recommend a ./build all d, in case any of the headers or library links have changed.
Mainly just for peace of mind that your binaries are built for your current libraries, and not old ones :)

John
 
Jeg got this on a centos 7 server I checked:

Code:
[root@server ~]# ldd /usr/local/directadmin/directadmin
        linux-vdso.so.1 =>  (0x00007fff82984000)
        libssl.so.10 => /lib64/libssl.so.10 (0x00007f558826c000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f5588035000)
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f5587c4d000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f5587a37000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f5587833000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f558754d000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f558731b000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f5587117000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f5586efc000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5586ce0000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f5586ad8000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f55867cf000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f55864cd000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f55862b7000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f5585ef5000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f5585ca9000)
        libfreebl3.so => /lib64/libfreebl3.so (0x00007f5585aa6000)
        [B]/lib64/ld-linux-x86-64.so.2 (0x00007f55884e4000)[/B]
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f5585896000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f5585692000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f558546c000)
        libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x00007f558521b000)
        liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f5584ff6000)
[root@server~]#

One line does not seem to be dynamic, I have put it in bold text. So do I need to recompile DirectAdmin?
 
I got it on the same line on Centos 6 x64.

Won't this be updated automatically once Directadmin 1.50 gets released?
 
No, DA does not need to be recompiled. That's a dynamic DA binary because you can see all libraries that are linked to it.
A static binary might look similar to this
Code:
freebsd8-64# ldd directadmin
ldd: directadmin: not a dynamic ELF executable

Also I believe the issue relates to glibc, so we can see the libc.so.6 directly in your linker output, so DA is fine.
The only case were you might need to be concerned is if the static ld-linux-x86-64.so.2 library is pointing to glibc.. but only if it's making calls to getaddrinfo...
I believe ld-linux is the actual linker library, hence it's static because it might not be able to use itself to link other files to itself using it's own code.. as if it's the hammer to make house, and you cannot make a hammer with a hammer (ok, bad analogy, lol)

Anyway, if the glibc issue were to apply to that module, then yum udpate would have updated it too.. so I don't think it's affected, so probably don't need to worry about ld-linux.

Short story, is your DA dynamic, so you don't need to worry about recompiling DA.
If glibc is updated, restart DA, and it will get the new library.

John
 
So with that logic DA does need to be recompiled for Debian 7 boxes:
Code:
# cat /etc/debian_version 
7.9
# ldd /usr/local/directadmin/directadmin
not a dynamic executable

while Debian 6 boxes look fine:
Code:
# cat /etc/debian_version 
6.0.10
# ldd /usr/local/directadmin/directadmin
	linux-vdso.so.1 =>  (0x00007ffd61534000)
	libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00007f7b39f0b000)
	libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007f7b39cd4000)
	libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00007f7b39931000)
	libmysqlclient.so.16 => /usr/local/mysql/lib/libmysqlclient.so.16 (0x00007f7b394d4000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f7b392d0000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f7b390b8000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f7b38da4000)
	libm.so.6 => /lib/libm.so.6 (0x00007f7b38b23000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f7b3890c000)
	libc.so.6 => /lib/libc.so.6 (0x00007f7b385a0000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f7b38384000)
	librt.so.1 => /lib/librt.so.1 (0x00007f7b3817b000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f7b3a16c000)
 
Hello,

I need help with a GLIBC vulnerability CVE-2015-8985 which I know that it is not related with this thread! (Sorry if I bothered you)

CVE-2015-8985 - Assertion failure in pop_fail_stack when executing a malformed regexp

Although it seems to be fixed in glibc 2.28, I've encountered the following issue testing on a Ubuntu 19.10 virtual machine with glibc 2.30-0ubuntu.2.1 the following program:

pop_fail_stack.c
#include <assert.h>
#include <regex.h>
#include <stdio.h>

int main(int argc, char **argv)
{
int rc;
regex_t preg;
regmatch_t pmatch[2];

rc = regcomp(&preg, "()*)|\\1)*", REG_EXTENDED);
assert(rc == 0);
regexec(&preg, "", 2, pmatch, 0);
regfree(&preg);
return 0;
}
pop_fail_stack: pop_fail_stack.c:12: main: Assertion `rc == 0' failed.
Aborted (core dumped)


As describes the Debian bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779392), the test program compiles an invalid regexp and then tries to match a string against it, triggers an assertion:
pop_fail_stack: regexec.c:1401: pop_fail_stack: Assertion `num >= 0' failed.
Aborted

So, in my scenario, the test program does not even successfully compile the invalid regexp.
Did anyone encounter this issue?
Could you please help me with this?

Thank you,
Raluca
 
Since you don't say what Distro you are on. I assume Debian


If you are on 2.28-10 or higher you are good.
 
Back
Top