LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   [Slackware security] vulnerabilities outstanding 20140101 (https://www.linuxquestions.org/questions/slackware-14/%5Bslackware-security%5D-vulnerabilities-outstanding-20140101-a-4175489800/)

mancha 07-14-2015 06:01 PM

Update 20150714 UTC

  1. Mozilla NSS

    Last week I explained that upgrading vulnerable OpenSSL packages is insufficient for secure transport if one doesn't also keep
    the default root store current (see post #401 & post #405).

    Now, I turn my attention to another important SSL/crypto stack, NSS.

    • NSS 3.17.3 more robustly decodes DER lengths to prevent attacks that inject arbitrary data to forge signatures, etc.
      (CVE-2014-1569)

    • NSS 3.18.1 updates the root store removing the MCS intermediate CA discovered to have issued fake google.com
      certificates and the e-Guven CA that has been unable/unwilling to submit public audits complying with Mozilla's
      requirements.

    • NSS 3.19 fixes a vulnerability to SMACK attacks that can force skipping ServerKeyExchange (CVE-2015-2721). This
      version also disables the unsafe SSLv3 protocol by default.

    • NSS 3.19.1 no longer accepts weak keys. This version increases minimum RSA, DSA, and DH key size minimums to
      512, 1023, and 1023 bits, respectively. See Logjam attack for more info. (CVE-2015-4000).

    • NSS 3.19.2 makes the previous fix (increased key lengths) specific to libssl (no longer impacts libfreebl).

    OpenSSL shouldn't be the only SSL/crypto stack to receive Bob's love. After all, Slackware staples such as Pidgin and
    NetworkManager use Mozilla's NSS. (Note: Slackware's Firefox, Thunderbird, and SeaMonkey also use NSS but they bundle
    their own versions so as long as you have the latest FF, TB, SM, you're OK with those three.
    )

    Recommendation: Slackware Linux should upgrade to NSS 3.19.2, asap.

    Note: Security-conscious slackers unwilling to wait for official updates can use Slackware's build files to install NSS 3.19.2
    plus NSPR 4.10.8. Simply get the source; edit version numbers; build:

    Code:

    --- a/mozilla-nss.SlackBuild
    +++ b/mozilla-nss.SlackBuild
    @@ -24,8 +24,8 @@
     
     PKGNAM=mozilla-nss
     SRCNAM=nss
    -VERSION=${VERSION:-3.16.5}
    -NSPR=${NSPR:-4.10.7}
    +VERSION=${VERSION:-3.19.2}
    +NSPR=${NSPR:-4.10.8}
     BUILD=${BUILD:-1_slack14.1}
     
     # Automatically determine the architecture we're building on:

--mancha

Who's your favorite dinosaur?

mralk3 07-14-2015 11:00 PM

Thanks mancha. I read this whole thread the other day and I've learned quite a bit from you. Much appreciated. Keep up the good work. :hattip:

tty30 07-15-2015 06:47 PM

Me too thanks to you @mancha!! I read you and learn alot but do not always understand it all. :D

mancha 07-16-2015 08:29 AM

20150716 UTC

  1. Apache HTTP Server

    core: Fix chunk header parsing defect. Remove apr_brigade_flatten(), buffering and duplicated code from the HTTP_IN filter,
    parse chunks in a single pass with zero copy. Limit accepted chunk-size to 2^63-1 and be strict about chunk-ext authorized
    characters. (CVE-2015-3183)

    Replacement of ap_some_auth_required (unusable in Apache httpd 2.4) with new ap_some_authn_required and ap_force_authn
    hook. (CVE-2015-3185)

    core: Fix a crash with ErrorDocument 400 pointing to a local URL-path with the INCLUDES filter active, introduced in 2.4.11.
    PR 57531. (CVE-2015-0253)

    mod_lua: A maliciously crafted websockets PING after a script calls r:wsupgrade() can cause a child process crash.
    (CVE-2015-0228)

    Recommendation: Slackware Linux should upgrade to Apache httpd 2.4.16 (sig)

--mancha

cwizardone 07-16-2015 09:29 AM

Quote:

Originally Posted by mancha (Post 5391452)
Update 20150714 UTC

[LIST=1][*]Mozilla NSS


...Recommendation: Slackware Linux should upgrade to NSS 3.19.2, asap.

Note: Security-conscious slackers unwilling to wait for official updates can use Slackware's build files to install NSS 3.19.2
plus NSPR 4.10.8. Simply get the source...

Done.
Many Thanks!
:hattip:

mancha 07-19-2015 05:45 AM

Update 20150719 UTC

  1. Apache Subversion

    As an update to my recommendation in post #200, Apache has released two versions since my write-up that fix four more
    vulnerabilities.

    Fixed in subversion 1.7.19:
    CVE-2014-3580: mod_dav_svn DoS from invalid REPORT requests.
    CVE-2014-8108: mod_dav_svn DoS from use of invalid transaction names.
    Fixed in subversion 1.7.20:
    CVE-2015-0248: Subversion mod_dav_svn and svnserve are vulnerable to a remotely triggerable assertion DoS vulnerability
    for certain requests with dynamically evaluated revision numbers
    CVE-2015-0251: Subversion HTTP servers allow spoofing svn:author property values for new revisions
    Recommendation: Slackware Linux should upgrade to subversion 1.7.20 (sig) or to the Apache-recommended 1.8.13.

--mancha

tty30 07-25-2015 01:52 AM

Hello, I am curious why does slackware security not upgrade ca-certificates or nss? Also does the new openssh attack affects slackware http://www.pcworld.com/article/29514...g-attacks.html?

Didier Spaier 07-25-2015 02:16 AM

Quote:

Originally Posted by tty30 (Post 5396014)
Also does the new openssh attack affects slackware http://www.pcworld.com/article/29514...g-attacks.html?

If I understand well, the article you linked to recommends some user settings. Generally speaking, Slackware lets the users configure and customize their system and ships vanilla software. In this specific case I see in /etc/sshd_config :
Code:

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Feel free to review the options in this file as shipped by Slackware and provide further advices.

allend 07-25-2015 02:20 AM

Quote:

Also does the new openssh attack affects slackware?
Default Slackware is vulnerable as it uses the default setting of ChallengeResponseAuthentication.
Explicitly enable
Code:

ChallengeResponseAuthentication no
in /etc/ssh/sshd_config to block the attack.
While editing the file, you could also shorten the default time for LoginGraceTime, as further protection.

55020 07-25-2015 02:31 AM

Quote:

Originally Posted by allend (Post 5396021)
Default Slackware is vulnerable as it uses the default setting of ChallengeResponseAuthentication.

*NO*

http://bsdly.blogspot.co.uk/2015/07/...hat-wasnt.html

http://marc.info/?l=openbsd-misc&m=143768798220775&w=2

Code:

home$ ssh -ld -oKbdInteractiveDevices=`perl -e 'print "pam," x 10000'` localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is fa:03:92:90:dc:f7:51:dc:a9:83:7e:8e:dc:9d:28:72.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
d@localhost's password:
Permission denied, please try again.
d@localhost's password:
Permission denied, please try again.
d@localhost's password:
Permission denied (publickey,password,keyboard-interactive).
home$

The big big clue that Slackware is not vulnerable is right in the middle of "perl -e 'print "pam," x 10000'"

allend 07-25-2015 02:32 AM

Correction gratefully acknowledged. Thanks!

mancha 07-28-2015 06:55 PM

Quote:

Originally Posted by tty30 (Post 5396014)
Hello, I am curious why does slackware security not upgrade ca-certificates or nss?

The Slackware team (PV+core maintainers) is a small group that doesn't include an InfoSec specialist. That probably influences
the distro's approach to security. However, for a definitive answer to your question you need to email PV directly.

Meanwhile, I'll continue donating some free time to reporting issues and developing security fixes for Slackware.

--mancha

PS My posting frequency will likely drop off somewhat but I'm not abandoning LQ-Slackware just spending a bit more time with
my BSDs and other Linux projects these days.

mralk3 07-28-2015 07:30 PM

Quote:

Originally Posted by mancha (Post 5397529)
The Slackware team (PV+core maintainers) is a small group that doesn't include an InfoSec specialist. That probably influences
the distro's approach to security. However, for a definitive answer to your question you need to email PV directly.

Meanwhile, I'll continue donating some free time to reporting issues and developing security fixes for Slackware.

--mancha

PS My posting frequency will likely drop off somewhat but I'm not abandoning LQ-Slackware just spending a bit more time with
my BSDs and other Linux projects these days.

What would be your recommendations for software to audit a Slackware installation? I do know a few of my own but I am curious what you recommend.

mancha 08-03-2015 07:53 PM

Update 20150803 UTC
  1. LXC

    A flaw allows an unprivileged user to use LXC to create arbitrary files on the filesystem and mount symlink attacks. (CVE-2015-1331)

    A flaw allows a malicious container to over-mount /proc which gets used by lxc-attach. This allows things such as the bypassing of
    containment from isolation mechanisms such as SELinux, AppArmor, and others. (CVE-2015-1334)

    Recommendation for Slackware-current: upgrade to LXC 1.0.7 (sig) and apply lxc-1.0_CVE-2015-1331.diff & lxc-1.0_CVE-2015-1334.diff.

    Recommendation for Slackware 14.1: Rather than spend time backporting the CVE-2015-1334 fix to 0.9.0, I'll just recommend 14.1 users
    upgrade to LXC 1.0.7 and follow the recommendations above. Note, Slackware-current builds LXC 1.0.x with the optional CGManager
    support. If you want this on 14.1, you'll need to add libnih and CGManager. But, LXC can also be built without this.
--mancha

PS Hi mralk3. Regarding your question about audit frameworks, it's a very interesting topic. I suggest you start a thread on this and maybe
narrow down the scope a bit.

mancha 08-05-2015 03:48 PM

Update 20150805 UTC
  1. Ghostscript

    Insufficient checks on memory allocation permits an overflow of an under-allocation triggered by an integer wraparound.
    A malicious attacker can use crafted input to leverage this for DoS or possibly code execution. (CVE-2015-3228)

    Solution for 14.1: Re-build Ghostscript 9.07 after applying ghostscript-9.x_CVE-2015-3228.diff. Note, you might want to
    also fix a flaw in GS 9.07's tifflzw & tiffpack initialization. See this post for details and solution.

    Solution for Current: Re-build Ghostscript 9.16 after applying ghostscript-9.x_CVE-2015-3228.diff.

    Note: PoC trigger for 64-bit Slackware:

    Code:

    $ ps2pdf CVE-2015-3228.ps
--mancha


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