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

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.

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

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

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

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

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:

• bash-4.1_CVE-2014-7169.diff
• bash-4.2_CVE-2014-7169.diff
• bash-4.3_CVE-2014-7169.diff

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

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?

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

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):
   
   
   • bash-3.1_var-affix.diff
   • bash-4.1_var-affix.diff
   • bash-4.2_var-affix.diff
   • bash-4.3_var-affix.diff
   
   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:
   
   
   • bash-3.1_CVE-2014-7186_CVE-2014-7187.diff
   • bash-4.1_CVE-2014-7186_CVE-2014-7187.diff
   • bash-4.2_CVE-2014-7186_CVE-2014-7187.diff
   • bash-4.3_CVE-2014-7186_CVE-2014-7187.diff
   
   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

That command isn't a properly designed test for any vulnerability - ignore it.

--mancha

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:

But like I said, it doesn't matter anymore. After upgrading it's solved. Shell session again:

Note: I never ran any custom package builds. It's all official packages.

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?

This is a quote of the ChangeLog for Slackware 12.2:

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

Slackware Releases

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