SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
A flaw in the Linux kernel DCCP network code allows remote (or local) attackers to cause a system crash (DoS) or potentially
execute arbitrary code via crafted DCCP packets (CVE-2014-2523).
The vulnerable code is in the kernel's DCCP connection tracker helper which Slackware builds as a module (both generic and
huge). In other words, if the DCCP conntrack module is not loaded (or not run via NOTRACK targets for example), the attack
vector is non-existent (see Prophylaxis).
Re-build kernel 3.10.17 after applying upstream fix (for 14.1 users)
Upgrade to 3.10.36 (for current or 14.1 users on the latest 3.10.x)
Upgrade to 3.2.57 (for 14.0 users; not yet released)
If you don't want to worry about patching or upgrading your kernel, you can remove the attack vector by ensuring the DCCP
conntrack helper module never loads:
A flaw in the TLS heartbeat extension code (introduced in version 1.0.1) can be exploited by attackers to reveal memory
connected to either a client or server using a vulnerable version (CVE-2014-0160 aka "heartbleed").
A design flaw in the way elliptic scalar multiplication is computed on curves defined over GF(2ᵐ) allows the recovery of
ECDSA nonces via flush+reload (CVE-2014-0076).
Notes: For the "heartbleed" bug, affected versions include 1.0.1-beta1 through 1.0.1f (inclusive) and 1.0.2-beta1. The 0.9.8
and 1.0.0 branches are not affected.
My initial report might not have transmitted the severity of the heartbeat vulnerability. At this point, any service linking a vulnerable
OpenSSL (1.0.1+) might have had its primary key material compromised. In other words, if you run such services you might need to
replace existing key material (e.g. web certificates, etc.). If your certificates are signed by an established CA, contact them about
the procedure for revocation and re-issuance of certificates. If you run a certificate authority yourself, take the necessary steps.
Client-side, credentials (or other private information) submitted by clients to vulnerable servers (login/password) are potentially
Hi mancha, I am trying to rebuild the new openssl version and it doesn't work
created directory `/tmp/package-openssl/etc'
created directory `/tmp/package-openssl/etc/ssl'
created directory `/tmp/package-openssl/etc/ssl/man'
created directory `/tmp/package-openssl/etc/ssl/man/man1'
created directory `/tmp/package-openssl/etc/ssl/man/man3'
created directory `/tmp/package-openssl/etc/ssl/man/man5'
created directory `/tmp/package-openssl/etc/ssl/man/man7'
cms.pod around line 457: Expected text after =item, not a number
cms.pod around line 461: Expected text after =item, not a number
cms.pod around line 465: Expected text after =item, not a number
cms.pod around line 470: Expected text after =item, not a number
cms.pod around line 474: Expected text after =item, not a number
POD document had syntax errors at /usr/bin/pod2man line 71.
make: *** [install_docs] Error 1
EDIT: I commented all the parts related to documentation on the slackbuild file but that is a bit annoying imo
Last edited by moisespedro; 04-08-2014 at 09:03 AM.
Use the source package in patches, not the one in the original source tree. That has worked for me without any issues. You need to remove openssl-1.0.1f.tar.gz and replace it with openssl-1.0.1g.tar.gz.
It was discovered version 1 intermediate certificates were being incorrectly considered CA certificates by default since
version 2.11.5. Systems with CAs in their trusted root certificate store, which issue X.509 version 1 certificates, are
potentially vulnerable. [CVE-2014-1959 / GNUTLS-SA-2014-1]
Solution: Upgrade to GnuTLS 3.1.21 or apply this fix.
No way! they still had the GnuTLS in there? What about OpenSSL I haven't yet installed my new slack sys yet haven't had the time so can't check. Niether will I be running a server so it doens't affect me but just curious... Which openssl patch did you guys use. Hopefully .g and not .f
.f got an F as a security patch.
Slackware 14.1's rsync 3.1.0 is vulnerable to a local/remote resource consumption denial of service attack (CVE assignment
pending). I've not personally checked other Slackware versions but a lightning code review suggests to me vulnerable code
exists since rsync 3.0.5 (i.e. Slackware 13.0).
Solution: Re-build rsync with upstream's fix  which I've mirrored at the vault.
comment = PoC for DoS
path = /tmp
read only = yes
list = yes
uid = nobody
gid = nobody
auth users = *
secrets file = /etc/rsyncd.secrets
A use-after-free race condition has been discovered in OpenSSL's read buffer (CVE-2010-5298). Under certain
circumstances, this flaw may permit an attacker to inject data from one connection into another.
Note: This might be a NOP when OpenSSL is not built with OPENSSL_NO_BUF_FREELIST. Nevertheless, my strong
recommendation is that everyone apply the fix.
The OpenSSL 0.9.8 branch is unaffected by this issue (vulnerable code was introduced in OpenSSL 1.0.0). Systems
running Slackware 13.37 and earlier require no action (unless they run a non-stock OpenSSL 1.0.0+).
Last edited by mancha; 04-14-2014 at 05:54 PM.
Reason: Mention 0.9.8 is unaffected
Technically there usually in no need to blacklist the conntrack dccp module unless you specifically load it yourself, and in this case simply don't load it. It is NOT loaded automatically, and NOT loaded by Alien Bob's firewall script.
what is difference between this code with just plain blacklist this modules in the file?
"Blacklisting" prevents a kernel module from being auto-loaded. However, I also want to prevent the vulnerable code from loading
via two additional methods: 1) accidental manual loading and 2) indirectly via a non-blacklisted kernel module that depends on it.