SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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).
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.
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."
Last edited by mancha; 03-26-2015 at 07:11 AM.
Reason: use https
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
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.
Last edited by Didier Spaier; 03-26-2015 at 11:42 AM.
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.
Last edited by mancha; 03-28-2015 at 08:05 AM.
Reason: clarify list and tracker are separate
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)
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.
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
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.
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)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.