LinuxQuestions.org - [Slackware security] vulnerabilities outstanding 20140101

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - [Slackware security] vulnerabilities outstanding 20140101 (https://www.linuxquestions.org/questions/slackware-14/%5Bslackware-security%5D-vulnerabilities-outstanding-20140101-a-4175489800/)

Suggested security upgrade for resolve CVE-2014-3560 (Remote code execution in nmbd), only Samba 4.0.0 to 4.1.10 are affected:

14.1 and Current upgrade to Samba 4.1.11 (sig)

Samba has just been updated to 4.1.11 according to the latest ChangeLog and security advisories.

OpenSSL has been updated to 1.0.1i and 0.9.8zb. They build fine under -current.
https://www.openssl.org/news/secadv_20140806.txt

OpenSSL packages updated according to the latest ChangeLog.

Update 20140906

glibc

Glibc 2.19, and earlier, have a vulnerability that allows directory traversal via crafted locale-related environment variables.
This is particularly worrisome when suid/sgid programs inherit these because of the possibility of arbitrary code execution
with elevated privileges. (CVE-2014-0475)

Loadable gconv transliteration modules in glibc 2.19, and earlier, have never worked properly and the implementation contains
serious security issues. A working root exploit has been made available for Fedora 20 that demonstrates the severity of this
flaw. (CVE-2014-5119)

Recommendation: re-build glibc 2.17 after applying my backported fixes for these two issues (glibc-2.17_CVE-2014-0475.diff &
glibc-2.17_CVE-2014-5119.diff).

Note: there are additional vulnerabilities in Slackware 14.1's glibc. See post #188 for details and instructions on how to fix them.
procmail

A heap overflow vulnerability was discovered in procmail's formail filter utility. (CVE-2014-3618)

CVE-2014-3618.mbox can be used to trigger the overflow (though it seems to only trigger on 64-bit Slackware):

Code:

$ formail -s < CVE-2014-3618.mbox > /dev/null

Recommendation: re-build procmail 3.22 after applying patch based on taviso's suggested fix (procmail-3.22_CVE-2014-3618.diff).

Note: Procmail 3.22 fails to compile with recent glibc's. Here's a diff against Slackware 14.1's procmail.SlackBuild so it handles
the security patch as well as glibc conflicts:

Code:

--- procmail.SlackBuild.pat +++ procmail.SlackBuild @@ -56,6 +56,13 @@ find . \ $ -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 $ \ -exec chmod 644 {} \; +# Avoid conflicts with glibc (20140904) +sed -i -e 's|getline|proc_getline|' src/fields.c src/formail.c \ + src/formisc.c src/formisc.h + +# Fix for CVE-2014-3618 (20140904) +patch -p1 --verbose < $CWD/procmail-3.22_CVE-2014-3618.diff || exit 1 + make || exit 1 cd src
gpgme

The possibility to trigger exploitable heap-based buffer overflows in the gpgsm and uiserver engines was discovered in gpgme 1.5.0,
and earlier. (CVE-2014-3564)

Recommendation: re-build gpgme 1.4.1 after applying my backported fix (gpgme-1.4.1_CVE-2014-3564.diff) or, alternatively, upgrade
to gpgme 1.5.1.
dbus

In dbus 1.6.20, and earlier, malicious clients can make dbus-daemon disconnect a system service using a vulnerability in the
handling of sendmsg() or by sending messages with fds in rapid succession. (CVE-2014-3532 and CVE-2014-3533, respectively)

Dbus 1.6.20, and earlier, contain a potential DoS vulnerability that under certain configurations could allow unauthorized
side-channel communication between processes. (CVE-2014-3477)

Recommendation: upgrade to dbus 1.6.22 (sig)
lzo

As GazL alerted us in post #194, a vulnerability was discovered in the LZO algorithm (and related LZ4 algorithm) with potentially
far-reaching implications because of the large number of things that implement them (e.g. lzo, ffmpeg, python-lz4, OpenVPN, Linux
kernel, etc.). This vulnerability has had its share of controversy with researchers disagreeing over severity and exploitability.

Nevertheless, lzo 2.07 fixes the potential integer overflow condition that can trigger buffer overruns in its "safe" decompressor
variants while processing maliciously crafted data. (CVE-2014-4607)

Recommendation: upgrade to lzo 2.08
file

A potential integer overflow in cdf_read_property_info was discovered in file 5.18, and earlier, that permits maliciously triggering
a DoS via specially-crafted CDF files. (CVE-2014-3587)

Recommendation: re-build file 5.14 after applying my backported fix (file-5.14_CVE-2014-3587.diff) or, alternatively, upgrade to
file 5.19.

Note: There are a couple of additional vulnerabilities in Slackware 14.1's file (CVE-2014-1943 and CVE-2014-2270). See post #96
for details and instructions on how to fix them.
subversion

Subversion 1.7.17, and earlier, improperly validate wildcards in SSL certs in ra_serf (note: only applicable if using serf).
(CVE-2014-3522)

Subversion 1.7.17, and earlier, have a vulnerability that can be exploited to cause credentials cached with svn to be sent to the
wrong server. (CVE-2014-3528)

Recommendation: upgrade to subversion 1.7.18 (sig)

--mancha

Quote:

Originally Posted by mancha (Post 5233498)

Update 20140906[*]glibc

Glibc 2.19, and earlier, have a vulnerability that allows directory traversal via crafted locale-related environment variables.
This is particularly worrisome when suid/sgid programs inherit these because of the possibility of arbitrary code execution
with elevated privileges. (CVE-2014-0475)

Loadable gconv transliteration modules in glibc 2.19, and earlier, have never worked properly and the implementation contains
serious security issues. A working root exploit has been made available for Fedora 20 that demonstrates the severity of this
flaw. (CVE-2014-5119)

Recommendation: re-build glibc 2.17 after applying my backported fixes for these two issues (glibc-2.17_CVE-2014-0475.diff &
glibc-2.17_CVE-2014-5119.diff).

Note: there are additional vulnerabilities in Slackware 14.1's glibc. See post #188 for details and instructions on how to fix them.

Does the backported glibc-fixes apply to 2.19 in -current as well?

Mats

2.20 has just been tagged in git, so I wouldn't bother rebuilding 2.19 for current. Decision is with Pat of course, but I expect 2.20 will turn up in current before too long.

If you don't want to wait though, the fix for 0475 appears to have been applied to release/2.19/master 2 days ago: https://sourceware.org/git/?p=glibc....0bd971de4aa163

Personally, if I were going to rebuild, I'd be inclined to just pull release/2.19/master and get all the other (non-security) fixes as well.

when you upgrade subversion 1.7.18, you might need to upgrade neon as well to latest 0.30.0 however I think there is typo in ./src/ne_openssl.c
for people disabled sslv2

Code:

--- ./src/ne_openssl.c.orig    2013-07-26 12:15:19.000000000 -0400

+++ ./src/ne_openssl.c          2014-09-07 12:33:28.000000000 -0400

@@ -580,7 +580,7 @@

        ne_free(ctx);

        return NULL;

 #else

-        ctx->ctx = SSL_CTX_new(SSLv2_server_method());

+        ctx->ctx = SSL_CTX_new(SSLv23_server_method());

        SSL_CTX_set_session_cache_mode(ctx->ctx, SSL_SESS_CACHE_CLIENT);

 #endif

    }

Quote:

Originally Posted by mats_b_tegner (Post 5233817)

Does the backported glibc-fixes apply to 2.19 in -current as well?

Hi Mats. Not without a bit of tweaking to the Makefile changes and some offsets (though my CVE-2014-5119 diff might apply more
cleanly because it only patches long-standing code). However, my patches have source attribution in their headers and in the case
of glibc patches I list the upstream commits I used to construct them.

By the way, glibc 2.20 (sig), which includes those fixes, was released today.

Quote:

Originally Posted by number22 (Post 5233936)

when you upgrade subversion 1.7.18, you might need to upgrade neon as well to latest 0.30.0 however I think there is typo in ./src/ne_openssl.c for people disabled sslv2

Hi number22. You're right, if your OpenSSL is built without SSLv2 support (which I believe a very wise decision; see post #163),
you need to update neon or rebuild Slackware 14.1's neon 0.29.6 after applying neon-0.29_disable-SSLv2.diff.

--mancha

Quote:

Originally Posted by mancha (Post 5233962)

Hi Mats. Not without a bit of tweaking to the Makefile changes and some offsets (though my CVE-2014-5119 diff might apply more
cleanly because it only patches long-standing code). However, my patches have source attribution in their headers and in the case of glibc patches I list the upstream commits I used to construct them.

By the way, glibc 2.20 (sig), which includes those fixes, was released today.

Ok, compiling glibc 2.20 halts when applying patches. Do you know which patches are necessary to build 2.20?

Mats

Update 20140909

Libgcrypt

Slackware 13.0-14.1 addressed CVE-2013-4576 in GnuPG-1 when it upgraded to GnuPG 1.4.16 on 20131220. However, Slackware's
GnuPG-2 remains vulnerable because Libgcrypt (which underlies GnuPG-2) wasn't updated.

I mentioned this in post #1 and back then my recommendation was to upgrade to Libgcrypt 1.6.0. Since writing that post, fixes have
been backported to the 1.5.x branch - specifically, they are included in Libgcrypt 1.5.4 (see: announcement).

Recommendation (revised): Upgrade to Libgcrypt 1.5.4 (sig) or, alternatively, upgrade to Libgcrypt 1.6.2 (sig). The latter requires
rebuilding GnuPG-2.

Note: An additional CVE-2014-5270 has been assigned to a method of exploiting the vulnerable code by touching exposed metal
(CVE-2013-4576 applies to acoustic attacks). Those interested can read this neat description.
ppp

It was announced a security vulnerability in which a potential integer overflow during option parsing can be exploited to overwrite the
heap was discovered in ppp 2.4.6, and earlier. (CVE-2014-3158)

Recommendation: Upgrade to ppp 2.4.7 (sig)

--mancha

Update 20140910

glibc

Regarding the glibc vulnerabilities I recently described in post #200 (CVE-2014-0475 & CVE-2014-5119), I've prepared the following
patches against glibc 2.19 for the benefit of Slackware-current users:
- glibc-2.19_CVE-2014-0475.diff
- glibc-2.19_CVE-2014-5119.diff

--mancha

Mancha, I went to try your two proof of concepts from here. I run them both, the one for CVE-2012-4412 gives me a segmentation fault and the second one works (in a few seconds I get an overflow).

And I am not being able to rebuild glibc. I got messages like this a few times:

Code:

patching file posix/tst-spawn.c

Using Plan A...

Reversed (or previously applied) patch detected!  Assume -R? [n] 

Apply anyway? [n] y

Hunk #1 FAILED at 168.

Hunk #2 FAILED at 221.

Hunk #3 FAILED at 254.

3 out of 3 hunks FAILED -- saving rejects to file posix/tst-spawn.c.rej

done

I wasn't sure on what should I have done.

This is my glibc.SlackBuild

http://paste.debian.net/120456/

Quote:

Originally Posted by moisespedro (Post 5236388)

And I am not being able to rebuild glibc....This is my glibc.SlackBuild http://paste.debian.net/120456/

You are trying to apply the CVE-2014-4043 patch twice. Remove lines 207-208 in the paste:

Code:

  # CVE-2014-4043

  patch -p1 --verbose < $CWD/glibc-2.17_CVE-2014-4043.diff || exit 1

Other than that, the slackbuild looks good (specifically the order of the security patches is correct).

Once you re-build and install glibc, if those PoCs run for at least 5 minutes with no errors you're no longer vulnerable.

--mancha