-   Slackware (
-   -   [Slackware security] vulnerabilities outstanding 20140101 (

moisespedro 09-11-2014 05:12 PM

Thanks, it builds fine now. I was looking at the file and I couldn't spot that.

moisespedro 09-11-2014 07:14 PM

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.

mancha 09-13-2014 10:38 AM

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

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

    Recommendation: upgrade to curl 7.38.0 (sig)

mancha 09-16-2014 05:55 PM

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.

    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 09-22-2014 05:51 PM

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 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 after applying net-snmp-
    Slackware-current is already on net-snmp so current users need only rebuild after applying the patch.

mancha 09-24-2014 12:04 PM

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:


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

mancha 09-24-2014 05:51 PM

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:


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

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


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?

mancha 09-24-2014 06:33 PM

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 09-26-2014 10:38 AM

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:


    $ 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

mancha 09-27-2014 01:58 AM


Originally Posted by coralfang (Post 5245119)
Just browsed through this and saw another variation

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.


rg3 09-27-2014 04:34 AM

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:


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

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:


| Upgrading bash-4.3.025-x86_64-2 package using bash-4.3.026-x86_64-1.txz


$ 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'
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 <>

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.

rouvas 09-28-2014 06:08 AM

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

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?

Didier Spaier 09-28-2014 07:16 AM

This is a quote of the ChangeLog for Slackware 12.2:

Fri Aug 30 06:26:06 UTC 2013
#                                                                  #
# 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  #

moisespedro 09-28-2014 01:25 PM

And you can always check this to know the EOL of Slackware relesses

Slackware Releases

mancha 09-28-2014 10:24 PM

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.


    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.

All times are GMT -5. The time now is 07:15 AM.