LinuxQuestions.org
Share your knowledge at the LQ Wiki.
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 09-11-2014, 04:12 PM   #211
moisespedro
Senior Member
 
Registered: Nov 2013
Location: Brazil
Distribution: Slackware
Posts: 1,223

Rep: Reputation: 195Reputation: 195

Thanks, it builds fine now. I was looking at the file and I couldn't spot that.
 
Old 09-11-2014, 06:14 PM   #212
moisespedro
Senior Member
 
Registered: Nov 2013
Location: Brazil
Distribution: Slackware
Posts: 1,223

Rep: Reputation: 195Reputation: 195
Mancha, the first PoC still doesn't run. I compiled both with "gcc .c". First one gives me a segmentation fault, second one runs, slows down the system but it doesn't show an error for a long time so I guess it is fine.
 
Old 09-13-2014, 09:38 AM   #213
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Update 20140913
  1. curl

    By not properly detecting and rejecting domain names for partial literal IP addresses when parsing received HTTP cookies, libcurl can
    be fooled into sending cookies to wrong sites and into allowing arbitrary sites to set cookies for others (see announcement for details).
    [CVE-2014-3613]

    Since version 7.31.0 libcurl wrongly allows cookies to be set for Top Level Domains (TLDs), thus giving them broader scope than allowed.
    This permits arbitrary sites to set cookies that could get sent to different and unrelated sites or domains (see announcement for details).
    [CVE-2014-3620]

    Recommendation: upgrade to curl 7.38.0 (sig)
--mancha
 
1 members found this post helpful.
Old 09-16-2014, 04:55 PM   #214
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Update 20140916

  1. dbus

    The following five dbus vulnerabilities, which affect dbus 1.6.22 and earlier in the 1.6 branch, have been recently fixed:

    On 64-bit platforms, under certain conditions, a malicious message-sender could pass one more fd through the kernel than recipient
    is expecting. If assertions are enabled this causes a dbus-daemon crash. Otherwise, the buffer can be overrun with the possibility
    for arbitrary code execution. (CVE-2014-3635)

    A malicious sender can open multiple connections to the system bus and queue up the maximum allowed number of fds. As a result,
    new clients would be unable to connect to dbus-daemon. Additionally, on Linux, a malicuous sender could craft multiple messages in
    a way that causes dbus-daemon to call sendmsg() with more that maximum allowed number of fds causing a fatal socket error and
    DoS. (CVE-2014-3636)

    It is possible for a malicious client to create D-Bus connections that persist after the creating process has already terminated. This
    issue allows for abusive behavior that makes it impossible to terminate D-Bus connections by killing originating processes.
    (CVE-2014-3637)

    Malicious senders can create a situation of extreme resource consumption by opening the maximum allowed number of parallel
    connections and sending the maximum allowed number of parallel methods on each connection causing subsequent method calls to
    be unreasonably slow. (CVE-2014-3638)

    Malicious senders can make repeated connection attempts that intentionally don't complete the authentication handshake to cause
    the majority of legitimate connection attempts to the daemon to fail. (CVE-2014-3639)

    Recommendation: Upgrade to dbus 1.6.24 (sig)

    Note: This supersedes the recommendation in post #200

  2. OpenSSL

    This is not a vulnerability report; rather a notice for those who have adopted my personal OpenSSL configuration options described
    in post #163. In particular, those who have chosen to disable SSL 2.0 should read the new thread I started about SSL 2.0 including
    the note at the end that describes a problem with my slackbuild.

--mancha

Last edited by mancha; 09-20-2014 at 02:52 AM. Reason: five vulns
 
Old 09-22-2014, 04:51 PM   #215
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Update 20140922
  1. net-snmp

    Releases from 5.5 through 5.7.2 are vulnerable to a potential remotely trigger-able denial of service attack on Linux when ICMP-MIB
    is in use. (CVE-2014-2284)

    Releases 5.7.2.1 and earlier are vulnerable to a remote denial-of-service attack due to how snmptrapd handles certain SNMP traps
    when started with the "-OQ" option. (CVE-2014-3565)

    Recommendation: Slackware 14.1 users should upgrade to net-snmp 5.7.2.1 after applying net-snmp-5.7.2.1_CVE-2014-3565.diff.
    Slackware-current is already on net-snmp 5.7.2.1 so current users need only rebuild after applying the patch.
--mancha
 
Old 09-24-2014, 11:04 AM   #216
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Update 20140924
  1. Bash

    A recently-disclosed flaw in how Bash evaluates environment variables can be exploited by an attacker who uses maliciously-crafted
    environment variables for code injection. This vulnerability has wide-ranging impact and can be remotely exploited. Exploit scenarios
    range from bypassing OpenSSH restrictions using TERM or SSH_ORIGINAL_COMMAND; code injection to Apache httpd with mod_cgi or
    mod_cgid and bash CGI scripts; etc. More details here. (CVE-2014-6271)

    Recommendation (for 14.1): Rebuild Bash 4.2 after applying Bash 4.2 Patch 048.
    Recommendation (for current): Rebuild Bash 4.3 after applying Bash 4.3 Patch 025.

    Note: Bash has issued patches as far back as version 3.0 so users of older Slackware versions (12.0 through 14.0) can get the relevant
    patch from Bash's patches directories: http://ftp.gnu.org/pub/gnu/bash/bash-X.Y-patches/.

    Test:
    Code:
    FOO='() { :;}; echo;echo Bash is vulnerable!' bash -c "echo If above line says vulnerable, apply patches"
--mancha

Last edited by mancha; 09-24-2014 at 12:09 PM. Reason: add test
 
3 members found this post helpful.
Old 09-24-2014, 04:51 PM   #217
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Update 20140924-1
  1. Bash

    Unfortunately, the patches released by Bash today don't quite make environment variable evaluation robust enough. As brought up by
    researcher Tavis Ormandy, one can still craft environment variables that have unwanted effects. The following copies /etc/passwd to
    file ~/mancha:

    Code:
    $ FOO='() { (a)=>\' bash -c "mancha cat /etc/passwd";
    While this might not be immediately exploitable, it does suggest the parsing code remains fragile. I'll post updates as they become available.
--mancha


Update #1

Bash's maintainer has shared a tentative fix for the above issue (which has been assigned CVE-2014-7169). Based on his proposal, I've prepared
patches for Bash 4.1, 4.2, and 4.3 and share them here for those who prefer to not wait for official patches:
Unlike official Bash patches that can be dropped into the patches dir and get automatically picked up on a re-run of the slackbuild, with these
you'll need to add a line to bash.SlackBuild just before the configure block. Remember to change the version minor, appropriately (in red):

Code:
patch -p1 --verbose < $CWD/bash-4.2_CVE-2014-7169.diff || exit
On my systems, the patch addresses the above issue. Challenge: after applying this patch, can you find yet another way to inject code via
env vars?

Last edited by mancha; 09-25-2014 at 03:54 AM. Reason: Add patches for CVE-2014-7169
 
1 members found this post helpful.
Old 09-24-2014, 05:33 PM   #218
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Update 20140924-2

So, it's an interesting day...
  1. Mozilla NSS

    While details are still scarce, Mozilla reports a serious vulnerability in its NSS suite making products that use it vulnerable to RSA
    certificate forgery. This impacts the following Mozilla products: NSS, Firefox, Thunderbird, and Seamonkey.

    Recommendation: Upgrade to Firefox 32.0.3 or Firefox ESR 24.8.1; Upgrade to Thunderbird 24.8.1; Upgrade to SeaMonkey 2.29.1;
    Upgrade to NSS 3.16.5.
--mancha

Last edited by mancha; 09-24-2014 at 05:55 PM.
 
Old 09-26-2014, 09:38 AM   #219
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Update 20140926
  1. Bash (\ˈbash\ v. to strike hard and forcefully)

    Upstream responded quickly to the recent Bash issues which was great. However, the band-aid approach hasn't been convincing in its
    ability to significantly reduce the attack surface related to function-carrying variables - it remains uncomfortably large.

    In this context, Florian Weimer of Red Hat has proposed hardening Bash's function importation from environment variables by imposing a
    specific prefix/suffix syntax: BASH_FUNC_myfunc(). This added protection for web apps, etc. is a welcome feature given CVE-2014-6271,
    CVE-2014-7169, and the potential for future exploit scenarios. I provide versions of Florian's hardening patch for Bash 3.1, 4.1, 4.2,
    and 4.3 for interested slackers (Debian and Red Hat are already deploying this feature):


    To recap where we stand with environment variables:

    1. The serious RCE issue that kicked off this Bash marathon was fixed in the latest upstream patches (included in Slackware's recent
      Bash release)
    2. The subsequent yacc-attack was fixed by one-liner patches I provided in post #217 that will be officially released by upstream
      todayish (included in Slackware's most recent Bash release - the second one)
    3. A hardening feature to provide an added layer of protection for potential targets such as web applications was developed and can
      be enabled by applying above affix patches (not included in Slackware's Bash releases)

    There's a bit more...

    Red Hat yesterday disclosed two out-of-bounds memory issues it discovered that apparently affect Bash back to 3.2 or earlier. They've
    been designated CVE-2014-7186 and CVE-2014-7187.

    To trigger one of them:

    Code:
    $ bash -c 'true <<YAP <<YAP <<YAP <<YAP <<YAP <<YAP <<YAP <<YAP <<YAP <<YAP <<YAP <<YAP'
    I've packaged Red Hat's solution for these two issues for Bash 3.1, 4.1, 4.2, and 4.3 and share with fellow slackers:


    Note: I'm currently running Bash 4.2 + official patches through 048 + one-liner patch + hardening patch + OOB patch and things are
    working as they should. My Bash is now unaffected by the tests in post #216 (RCE vuln.), post #217 (yacc-attack), and this post
    (YAP-attack).
--mancha

Last edited by mancha; 09-27-2014 at 09:50 AM. Reason: clarity
 
5 members found this post helpful.
Old 09-27-2014, 12:58 AM   #220
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by coralfang View Post
Just browsed through this https://bugzilla.redhat.com/show_bug.cgi?id=1141597 and saw another variation
Code:
env -i X='() { (a)=>\' bash -c "echo Vulnerable"''
Still vulnerable according to this
That command isn't a properly designed test for any vulnerability - ignore it.

--mancha
 
6 members found this post helpful.
Old 09-27-2014, 03:34 AM   #221
rg3
Member
 
Registered: Jul 2007
Distribution: Fedora
Posts: 527

Rep: Reputation: Disabled
Thumbs up

Ok, the matter seems to be solved with the updated package from "Fri Sep 26 22:23:32 UTC 2014". I'm now seeing the expected results.

However, before upgrading and just for completeness I reinstalled bash-4.3.025-x86_64-2, launched a new shell and ran the test again. It did fail. Here's the shell session:

Code:
$ mkdir cve-2014-7169-test
$ cd cve-2014-7169-test/
$ ls -l
total 0
$ env X='() { (a)=>\' bash -c "echo date"; cat echo
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
Sat Sep 27 10:19:55 CEST 2014
$ ls -l
total 4
-rw------- 1 rg3 users 30 Sep 27 10:19 echo
$ cat echo
Sat Sep 27 10:19:55 CEST 2014
$ sha1sum /bin/bash
6810e7a082e68bd691a467bcff75548e9e429247  /bin/bash
$ bash --version
GNU bash, version 4.3.25(1)-release (x86_64-slackware-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
But like I said, it doesn't matter anymore. After upgrading it's solved. Shell session again:

Code:
+==============================================================================
| Upgrading bash-4.3.025-x86_64-2 package using bash-4.3.026-x86_64-1.txz
+==============================================================================
Code:
$ mkdir cve-2014-7169-test-again
$ cd cve-2014-7169-test-again
$ ls -l
total 0
$ env X='() { (a)=>\' bash -c "echo date"; cat echo
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
date
cat: echo: No such file or directory
$ sha1sum /bin/bash
5ef649adebb52763c1e993e4e6fc7e85ded4775e  /bin/bash
$ bash --version
GNU bash, version 4.3.26(1)-release (x86_64-slackware-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ ls -l
total 0
Note: I never ran any custom package builds. It's all official packages.
 
Old 09-28-2014, 05:08 AM   #222
rouvas
Member
 
Registered: Aug 2006
Location: Greece
Distribution: Slackware.12.2
Posts: 104
Blog Entries: 3

Rep: Reputation: 20
What is the oldest Slackware version supported for security updates?

I still have a 12.2 machine in production and I don't see any updates for bash at http://slackware.osuosl.org/.

Am I looking at the correct place? Newer Slackware versions seems to have already been patched.

Am I too hasty? Maybe the patch for older version will take some more time...

Can anyone shed some light on this?
 
Old 09-28-2014, 06:16 AM   #223
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,437

Rep: Reputation: Disabled
This is a quote of the ChangeLog for Slackware 12.2:
Code:
Fri Aug 30 06:26:06 UTC 2013
####################################################################
# NOTICE OF INPENDING EOL (END OF LIFE) FOR OLD SLACKWARE VERSIONS #
#                                                                  #
# Effective December 9, 2013, security patches will no longer be   #
# provided for the following versions of Slackware (which will all #
# be more than 5 years old at that time):                          #
#   Slackware 12.1, Slackware 12.2.                                #
# If you are still running these versions you should consider      #
# migrating to a newer version (preferably as recent as possible). #
# Alternately, you may make arrangements to handle your own        #
# security patches.  If for some reason you are unable to upgrade  #
# or handle your own security patches, limited security support    #
# may be available for a fee.  Inquire at security@slackware.com.  #
####################################################################

Last edited by Didier Spaier; 09-28-2014 at 12:53 PM.
 
Old 09-28-2014, 12:25 PM   #224
moisespedro
Senior Member
 
Registered: Nov 2013
Location: Brazil
Distribution: Slackware
Posts: 1,223

Rep: Reputation: 195Reputation: 195
And you can always check this to know the EOL of Slackware relesses

Slackware Releases

Last edited by moisespedro; 09-28-2014 at 12:27 PM.
 
Old 09-28-2014, 09:24 PM   #225
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Update 20140928
  1. Bash

    Bash has released a new set of patches based on Florian Weimer's hardening proposal (the "affix" patches I shared in post #219).
    All you need to do is download the one for your version to your Bash patches directory and re-run the slackbuild. It'll detect the
    new patch. If you're currently using the "affix" patch, though, make sure to no longer apply it when building with the latest upstream
    patch (list below).

    I can share at this time that a couple of additional issues have been identified with the parser. In at least one case the vulnerability
    is purported to allow remote code execution (like the original shellshock vulnerability did). These issues will shortly be made public
    so applying this hardening patch should be a top priority. The patch prevents exposure to these issues in particular and, more generally,
    significantly shrinks the external attack surface.

    Code:
    Version  Patch   Link
    
    3.1       20     bash31-020
    4.1       14     bash41-014
    4.2       50     bash42-050
    4.3       27     bash43-027
    Note: Those on Bash 4.2 should also re-download the previous patch (bash42-049). It was corrected to apply cleanly.
--mancha

Last edited by mancha; 09-30-2014 at 01:40 AM. Reason: Fix link after LQ thread merge/de-merge
 
  


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 09:08 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 12:43 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
Open Source Consulting | Domain Registration