LinuxQuestions.org - [Slackware security] vulnerabilities outstanding 20140101

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

20150319

OpenSSL

OpenSSL has published a new advisory that summarizes 13 new vulnerabilities ranging from High to Low severity as determined
by the OpenSSL team according to their severity scale. The good news is the vulnerability rated High doesn't affect Slackware
(only present in the 1.0.2 branch).

Of the 13 vulnerabilities, 7 affect Slackware (5 Moderate; 2 Low).

Solution for 12.0-13.37: Upgrade to OpenSSL 0.9.8zf (sig)

Solution for 14.0-current: Upgrade to OpenSSL 1.0.1m (sig) [compat 0.9.8zf]

--mancha

@mancha, thanks for all the work.

Are you aware if we are to expect a formal announcement from the slackware-security list?

php-5.4.39 is out.

Quote:

The PHP development team announces the immediate availability of PHP 5.4.39. Six security-related bugs were fixed in this release, including CVE-2015-0231, CVE-2015-2305 and CVE-2015-2331. All PHP 5.4 users are encouraged to upgrade to this version.

http://us.php.net/distributions/php-5.4.39.tar.bz2
http://us.php.net/distributions/php-5.4.39.tar.bz2.asc

Quote:

Originally Posted by rouvas (Post 5335014)

@mancha, thanks for all the work.

Are you aware if we are to expect a formal announcement from the slackware-security list?

Hi rouvas - thanks!

I'm afraid I don't have an answer for you. You'll have to contact Pat directly for more information.

Meantime, Slackware 14.0 (and later) users can use the build materials I've just put together for interested slackers. Save the
script below as opensslbuild.sh and run it:

Code:

# sh opensslbuild.sh

The script verifies PGP signatures of source tarballs which means you need Matt Caswell's PGP key in your keyring. If you decide
to skip signature verification (I recommend you don't), you can run the script as:

Code:

# gpg=no sh opensslbuild.sh

Note: I use slightly modified official Slackware build scripts. I make no changes to the Slackware configuration options but do not
force "-march=i486 -mtune=i686" compiler flags for x86 builds. You're probably not building to distribute, after all.

Enjoy.

--mancha

==========

Code:

#!/bin/bash



#-----------------------------------------------#

#    Slackware 14+ OpenSSL Package Builder    #

#                by: mancha                    #

#                                              #

# Note: signature verification requires having  #

# Matt Caswell's PGP key in your keyring. Link  #

# to key here: https://www.openssl.org/about/  #

#-----------------------------------------------# 



mver=20150325

ossl0=0.9.8zf

ossl1=1.0.1m

gpg=${gpg:-yes}



builddir=$(mktemp -p /tmp -d openssl.XXXXXX)

[ -z "$builddir" ] && { echo "error creating temporary dir"; exit 1; }

( cd $builddir || exit 1

  wget https://sf.net/projects/slackdepot/files/openssl/openssl-slack-${mver}.tar.bz2 || exit 1

  tar xf openssl-slack-${mver}.tar.bz2 || exit 1

  cd openssl-slack || 1

  wget https://openssl.org/source/openssl-${ossl0}.tar.gz || exit 1

  wget https://openssl.org/source/openssl-${ossl1}.tar.gz || exit 1



  if [ "$gpg" == "yes" ]

  then

    wget https://openssl.org/source/openssl-${ossl0}.tar.gz.asc || exit 1

    wget https://openssl.org/source/openssl-${ossl1}.tar.gz.asc || exit 1

    gpgv --keyring=~/.gnupg/pubring.gpg openssl-${ossl0}.tar.gz.asc \

          2>/dev/null || { echo "error validating sig" ; exit 1; }

    gpgv --keyring=~/.gnupg/pubring.gpg openssl-${ossl1}.tar.gz.asc \

          2>/dev/null || { echo "error validating sig" ; exit 1; }

  fi



  mv openssl-${ossl0}.tar.gz* openssl0

  sh ./openssl.SlackBuild

) \

&& echo "New packages in /tmp. You can now safely remove $builddir" \

|| echo "There was a build error."

Update 20150326

Mozilla Firefox and SeaMonkey

Another thread recently discussed Firefox security and prompted me to take a look at Slackware's versions. As of today, Slackware
14.1 is at FF ESR 31.5 and Slackware current at FF 36.0.1 (both are at SeaMonkey 2.32.1). Unfortunately, all these versions are
outdated and have publicly-disclosed critical vulnerabilities.
- Fixed in FF ESR 31.5.2 & FF 36.0.3 & SeaMonkey 2.33.1:
  Bounds checking flaw in JIT can be leveraged into OOB access allowing for arbitrary code execution. (CVE-2015-0817 /
  MFSA2015-29)
- Fixed in FF ESR 31.5.3 & FF 36.0.4 & SeaMonkey 2.33.1:
  Flaw in the processing of SVG format content allows bypassing same-origin protections that can be exploited to run arbitrary
  scripts with escalated privileges. (CVE-2015-0818 / MFSA2015-28)
Recommendations:
- Upgrade to FF 36.0.4 using ruario's script and Mozilla's binaries while awaiting Slackware updates
- Don't use SeaMonkey until Slackware releases updates

--mancha

Thanks mancha.

That leads to a question or request: would it be possible to communicate this kind of information through a mailing list? LQ is not easily if at all usable by blind people (try in links or lynx to check). Maybe the unofficial Slackware mailing list? This one or another, a mailing list is more easily accessible by blind people than this website.

There is already the official slackware-security mailing list, but of course that's only for officially released patches.

Anyone feel free to open another thread to answer with a specific topic, then I will add a link to this new thread in this post.

I also recommend using a mailing list, otherwise this thread could get very large.

Quote:

Originally Posted by Didier Spaier (Post 5337901)

Thanks mancha.

That leads to a question or request: would it be possible to communicate this kind of information through a mailing list?

Hi Didier. You're welcome.

I very much like the idea of an open & active Slackware security email discussion list complemented by some kind of tracker (e.g.
Bugzilla). Unfortunately, neither exist.

The list you linked is rather small (I count only 30 posters in 2014). This might be OK as long as the list's owner makes archives
available to non-members. Do you know who runs the list and why its archives are private?

Meantime, LQ-Slackware, with its large & lively membership and semi-official status, is a good platform for broad-based security
information dissemination and discussion. I'm aware using LQ for this has its drawbacks (e.g. large threads are hard to follow, can't
work offline, etc.). Then again, what platform doesn't have drawbacks?

--mancha

PS As to access for the disabled, I'm terribly ignorant on the state-of-the-art of assistive computer technologies but Jeremy Garcia
might be interested to hear from the blind Slackware users you know regarding how to improve LQ's accessibility.

Update 20150407

ntp
- When ntpd is configured to use a symmetric key to authenticate a remote NTP server/peer, it will process packets without MACs as
  if they had valid MACs allowing an attacker to hijack the communication without the need for the symmetric key. (CVE-2015-1798)
- NTP authentication doesn't properly protect established peer-to-peer symmetric associations from 3rd party injection of non-
  authenticated packets. By carefully crafting packets to peers in a symmetric association, an attacker can effectively deny service.
  (CVE-2015-1799)
Solution (for 14.1 and current): upgrade to ntp 4.2.8p2 (md5)

--mancha

Update 20150411

Mozilla Firefox

Since my 20150326 report in post #350 above, eight new critical vulnerabilities (along with several rated high, moderate, and low)
have been identified and fixed in Firefox. Below I list the critical issues:

Fixed in FF 37.0.1:
- Server certificate verification bypass with Alt-Svc (CVE-2015-0799)
Fixed in FF 37:
- Use-after-free due to flaws in HTMLSourceElement::AfterSetAttr (CVE-2015-0803)
- Use-after-free due to flaws in in HTMLSourceElement::BindToTree (CVE-2015-0804)
- Memset crash in mozilla::layers::BufferTextureClient::AllocateForSurface (CVE-2015-0805)
- Negative-size-param memset in mozilla::layers::BufferTextureClient::AllocateForSurface (CVE-2015-0806)
- Memory safety bugs (CVE-2015-0814)
Fixed in FF 37 and FF ESR 31.6:
- heap-use-after-free at AppendElements (CVE-2015-0813)
- Memory safety bugs (CVE-2015-0815)
Recommendation: Use ruario's script to download and repackage Mozilla's FF 37.0.1 binary release; then upgrade.

--mancha

this is an interesting problem
http://lists.x.org/archives/xorg-ann...il/002561.html
I think this means everything that uses a macro and was build with the problem version needs to be rebuild.

Quote:

Originally Posted by a4z (Post 5347653)

this is an interesting problem
http://lists.x.org/archives/xorg-ann...il/002561.html
I think this means everything that uses a macro and was build with the problem version needs to be rebuild.

Affected slackware packages seems to be cairo, libX11, libXext, libXfixes, libXi, libXrandr, libXrender, libXv, libXxf86misc, mozilla-firefox, mozilla-thunderbird, sdl, seamonkey and xf86-video-vmware.
See http://pastebin.com/g50rxGtU for output of grep on the soures in slackware-14.1.

Hopefully I'm not duplicating, but I couldn't find anything on this list for the security vulnerabilities in mariadb 5.5.40 that is the latest in 14.1 and current, they were fixed in 5.5.41 on Dec 21 2014

https://mariadb.com/kb/en/mariadb/ma...release-notes/

It fixes six vulnerabilities

CVE-2015-0411 CVSS v2 Base Score: 7.5 (HIGH)
CVE-2015-0382 CVSS v2 Base Score: 4.3 (MEDIUM)
CVE-2015-0381 CVSS v2 Base Score: 4.3 (MEDIUM)
CVE-2015-0432 CVSS v2 Base Score: 4.0 (MEDIUM)
CVE-2014-6568 CVSS v2 Base Score: 3.5 (LOW)
CVE-2015-0374 CVSS v2 Base Score: 3.5 (LOW)

Update 20150420

PHP

PHP recently released version 5.4.40 that fixes 14 security-related issues including a potential remote code execution vulnerability
in apache2handler (CVE-2015-3330). Also fixed: an assortment of buffer overflows, null pointer dereferences, and use-after-frees.

Recommendation: Upgrade to php 5.4.40 (sig)

--mancha

PS pataphysician, you're not duplicating - thanks for the mariadb alert.

Update 20150423

Curl
- A bug in curl's NTLM authentication implementation can under certain circumstances cause non-authenticated requests to re-use
  existing NTLM authenticated connections. (CVE-2015-3143)
- A vulnerability in fix_hostname can trigger out of bounds memory access. (CVE-2015-3144)
- A flaw in sanitize_cookie_path can be triggered by crafted input to corrupt heap memory. (CVE-2015-3145)
- A bug in curl's "negotiate" authentication protocol implementation caused it to incorrectly re-use an existing authenticated
  connection for subsequent requests. (CVE-2015-3148)
Recommendation: Upgrade to curl 7.42.0 (sig)

--mancha