LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 08-01-2014, 07:23 AM   #196
sardinha
Member
 
Registered: Aug 2012
Location: Portugal
Distribution: Slackware, Salix OS
Posts: 51

Rep: Reputation: 10
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)
 
Old 08-02-2014, 04:34 AM   #197
mats_b_tegner
Member
 
Registered: Nov 2009
Location: Gothenburg, Sweden
Distribution: Slackware64
Posts: 145

Rep: Reputation: 47
Samba has just been updated to 4.1.11 according to the latest ChangeLog and security advisories.
 
Old 08-07-2014, 02:36 PM   #198
mats_b_tegner
Member
 
Registered: Nov 2009
Location: Gothenburg, Sweden
Distribution: Slackware64
Posts: 145

Rep: Reputation: 47
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
 
1 members found this post helpful.
Old 08-08-2014, 05:51 PM   #199
mats_b_tegner
Member
 
Registered: Nov 2009
Location: Gothenburg, Sweden
Distribution: Slackware64
Posts: 145

Rep: Reputation: 47
OpenSSL packages updated according to the latest ChangeLog.
 
Old 09-06-2014, 03:41 PM   #200
mancha
Member
 
Registered: Aug 2012
Posts: 362

Original Poster
Rep: Reputation: Disabled
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

Last edited by mancha; 09-07-2014 at 01:48 AM. Reason: sed like a boss / add procmail reproducer
 
10 members found this post helpful.
Old 09-07-2014, 08:04 AM   #201
mats_b_tegner
Member
 
Registered: Nov 2009
Location: Gothenburg, Sweden
Distribution: Slackware64
Posts: 145

Rep: Reputation: 47
Quote:
Originally Posted by mancha View Post
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
 
Old 09-07-2014, 08:53 AM   #202
GazL
Senior Member
 
Registered: May 2008
Posts: 3,503

Rep: Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026Reputation: 1026
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.

Last edited by GazL; 09-07-2014 at 09:23 AM.
 
Old 09-07-2014, 02:06 PM   #203
number22
Member
 
Registered: Sep 2006
Location: Earth
Distribution: Slackware 14.1 Slackware64-current multilib
Posts: 211
Blog Entries: 2

Rep: Reputation: Disabled
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
     }
 
Old 09-07-2014, 03:34 PM   #204
mancha
Member
 
Registered: Aug 2012
Posts: 362

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by mats_b_tegner View Post
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 View Post
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

Last edited by mancha; 09-16-2014 at 10:47 PM. Reason: no need to define macro
 
2 members found this post helpful.
Old 09-08-2014, 04:57 AM   #205
mats_b_tegner
Member
 
Registered: Nov 2009
Location: Gothenburg, Sweden
Distribution: Slackware64
Posts: 145

Rep: Reputation: 47
Quote:
Originally Posted by mancha View Post
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

Last edited by mats_b_tegner; 09-08-2014 at 06:14 AM.
 
Old 09-09-2014, 03:58 PM   #206
mancha
Member
 
Registered: Aug 2012
Posts: 362

Original Poster
Rep: Reputation: Disabled
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
 
Old 09-10-2014, 02:27 AM   #207
mancha
Member
 
Registered: Aug 2012
Posts: 362

Original Poster
Rep: Reputation: Disabled
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
 
1 members found this post helpful.
Old 09-11-2014, 03:55 PM   #208
moisespedro
Senior Member
 
Registered: Nov 2013
Location: Brazil
Distribution: Slackware
Posts: 1,140

Rep: Reputation: 152Reputation: 152
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).
 
Old 09-11-2014, 04:03 PM   #209
moisespedro
Senior Member
 
Registered: Nov 2013
Location: Brazil
Distribution: Slackware
Posts: 1,140

Rep: Reputation: 152Reputation: 152
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/
 
Old 09-11-2014, 04:46 PM   #210
mancha
Member
 
Registered: Aug 2012
Posts: 362

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by moisespedro View Post
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

Last edited by mancha; 09-11-2014 at 04:49 PM.
 
  


Reply

Tags
exploit, security, slackware


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[Slackware Security]: Some pending vulnerabilities... mancha Slackware 7 08-22-2013 10:08 AM


All times are GMT -5. The time now is 03:16 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration