LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   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/)

sardinha 08-01-2014 07:23 AM

Samba 4
 
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)

mats_b_tegner 08-02-2014 04:34 AM

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

mats_b_tegner 08-07-2014 02:36 PM

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

mats_b_tegner 08-08-2014 05:51 PM

OpenSSL packages updated according to the latest ChangeLog.

mancha 09-06-2014 03:41 PM

Update 20140906

  1. 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.

  2. 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

  3. 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.

  4. 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)

  5. 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

  6. 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.

  7. 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

mats_b_tegner 09-07-2014 08:04 AM

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

GazL 09-07-2014 08:53 AM

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.

number22 09-07-2014 02:06 PM

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
    }


mancha 09-07-2014 03:34 PM

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

mats_b_tegner 09-08-2014 04:57 AM

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

mancha 09-09-2014 03:58 PM

Update 20140909

  1. 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.

  2. 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

mancha 09-10-2014 02:27 AM

Update 20140910

  1. 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:


--mancha

moisespedro 09-11-2014 03:55 PM

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).

moisespedro 09-11-2014 04:03 PM

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/

mancha 09-11-2014 04:46 PM

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


All times are GMT -5. The time now is 10:58 PM.