[Slackware security] vulnerabilities outstanding 20140101

moisespedro · 09-11-2014, 04:12 PM

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

moisespedro · 09-11-2014, 06: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, 09:38 AM

Update 20140913

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

mancha · 09-16-2014, 04:55 PM

Update 20140916

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

mancha · 09-22-2014, 04:51 PM

Update 20140922

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

mancha · 09-24-2014, 11:04 AM

Update 20140924

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

mancha · 09-24-2014, 04:51 PM

Update 20140924-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?

mancha · 09-24-2014, 05:33 PM

Update 20140924-2

So, it's an interesting day...

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

mancha · 09-26-2014, 09:38 AM

Update 20140926

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

mancha · 09-27-2014, 12:58 AM

Quote:

Originally Posted by coralfang

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

rg3 · 09-27-2014, 03: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:

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.

rouvas · 09-28-2014, 05: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 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?

Didier Spaier · 09-28-2014, 06:16 AM

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

moisespedro · 09-28-2014, 12:25 PM

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

Slackware Releases

mancha · 09-28-2014, 09:24 PM

Update 20140928

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