Update 20140407-1

1. Linux kernel
   
   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).
   
   Solution(s):
   
   
   • 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)
   
   Prophylaxis:
   
   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:
   
   Code:

   # echo "install nf_conntrack_proto_dccp /bin/true" > /lib/modprobe.d/CVE-2014-2523.conf

--mancha

2 members found this post helpful.

Update 20140407-2

1. OpenSSL
   
   Issues:
   
   
   1. 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").
      
      
   2. 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).
   
   Solution: Upgrade to OpenSSL 1.0.1g (sig).
   
   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.

--mancha

========

Update #1

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

Interested parties can read this rather good explanation: http://heartbleed.com/

Update #2

The good folks at Nmap (specifically Patrik Karlsson) have written a "heartbleed" detection script based on Jared Stafford's reproducer.

I've made minor tweaks and placed it at the vault for people wishing to test their systems: ssl-heartbleed.nse

Update #3

There is secondary public confirmation white hats have succeeded in stealing private keys using heartbleed.

4 members found this post helpful.

Hi mancha, I am trying to rebuild the new openssl version and it doesn't work

Any idea/fix?

EDIT: I commented all the parts related to documentation on the slackbuild file but that is a bit annoying imo

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.

Thanks metageek, it worked

Official updates from slackware also arrived today

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.

Just in case you didn't look yet at the Slackware's Security Advisories and ChangeLogs, openssl and openssl-solibs where upgraded to version 1.0.1g on Tue Apr 8, as already stated by Willy.

See also updates in post #122 of this thread from Mancha.

Update 20140414

1. rsync
   
   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 [1] which I've mirrored at the vault.
   
   PoC:
   
   /etc/rsyncd.conf
   
   Code:

   [pub]
    comment = PoC for DoS
    path = /tmp
    read only = yes
    list = yes 
    uid = nobody
    gid = nobody
    auth users = *
    secrets file = /etc/rsyncd.secrets

   /etc/rsyncd.secrets
   
   Code:

   bob:1337

   As bob: everything's OK
   
   Code:

   $ RSYNC_PASSWORD=1337 rsync rsync://bob@127.0.0.1/pub

   As non-existent user "dos": 100% CPU usage
   
   Code:

   $ RSYNC_PASSWORD=1337 rsync rsync://dos@127.0.0.1/pub

--mancha

[1] https://git.samba.org/?p=rsync.git;a...f;h=0dedfbce2c

1 members found this post helpful.

Update 20140414-1

1. OpenSSL
   
   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.
   
   Solution: Re-build OpenSSL 1.0.1g with this fix.

--mancha

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.

========

Update #1

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+).

2 members found this post helpful.

what is difference between this code with just plain blacklist this modules in the file?
Thanks

Basically, if you don't know what DCCP is, you should be save to blacklist it.. If that's what you asked.. (I've understood the question after metaschima's answer below)

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.

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

The solution I posted handles all three cases.

--mancha

2 members found this post helpful.

thanks mancha for explaining.
for further references, checking modprobe manual.