Quite right, he does mention that it's aimed at newer kernels in his post on Full Disclosure. Thought I'd try it anyway seeing as I have a few machines to do it on.

And thank you very much for testing different kernels and reporting back your findings. Please continue to do so. I was just
raising a warning flag so you don't mistakenly let your guard down when the PoC is unable to secure a root shell.

This PoC doesn't provide a root shell but races to crash the kernel. Is it effective on your 3.13.9?

The following tentative vulnerability status table I've put together might help:

--mancha

Update 20140519 (CVE-2014-0196 - linux kernel)

I have a bit of bad news. Over the weekend I reviewed my initial analysis and discussed it with a couple of kernel devs. I was correct
about concurrency control introduced in 3.5 mitigating the issue. However, that control gets relaxed earlier (in 3.9 rather than 3.12).

Unfortunately, this means Slackware 14.1 (shipping kernel 3.10.17) is vulnerable. The good news is the fix is unintrusive enough that
Slackware can push patched 3.10.17 kernels without much concern for regressions.

Older Slackware versions also ship vulnerable kernels (you can look yours up in the table above).

Solution(s) for Slackware 14.1:

• Re-build 3.10.17 after applying upstream fix (sig)
  

  OR

• Upgrade to 3.10.40 (or 3.12.20 or 3.14.4)

--mancha

1 members found this post helpful.

Update 20140521

1. MariaDB
   
   Several vulnerabilities have been discovered in MariaDB:
   
   
   Code:

   CVE-2014-0384    CVE-2014-2432
   CVE-2014-2419    CVE-2014-2436
   CVE-2014-2430    CVE-2014-2438
   CVE-2014-2431    CVE-2014-2440

   Solution: Upgrade to MariaDB 5.5.37 (MD5)
   
   --mancha

Update 20140530

1. GnuTLS
   
   A vulnerability (CVE-2014-3466) has been discovered in GnuTLS which allows a malicious server to corrupt the memory
   of a client using GnuTLS for TLS transport.
   
   Solution for Slackware 14.1/current: Upgrade to GnuTLS 3.1.25 (sig)
   
   
2. libtasn1
   
   Several vulnerabilities have been discovered in libtasn1 related to its handling of ASN.1 input (CVE-2014-3467,
   CVE-2014-3468, CVE-2014-3469).
   
   Solution for Slackware 14.1/current: Upgrade to libtasn1 3.6 (sig)

--mancha

Update 20140602

1. Sendmail
   
   A security-related bug in the handling of file descriptions was discovered that could be exploited by local users who are able to
   control mail delivery (e.g. via procmail, etc.) to interfere with an open SMTP connection (CVE-2014-3956).
   
   Solution: Upgrade to Sendmail 8.14.9 (sig)

--mancha

Is this a new bug or is the same from #155?
http://arstechnica.com/security/2014...ve-by-attacks/

It's the first vulnerability I mention in #155 (CVE-2014-3466). Here's a nice analysis though it is rather technical.

--mancha

Need to upgrade to gnutls 3.1.25 (Slackware 14.1 is currently 3.1.22)

BTW, I think there was also some recent PHP ones:


This thread is getting a little long and confusing now, a catch-up summary of what is still outstanding in 14.1 and -current would certainly be helpful if anyone has that info to hand, going back over 11 pages of what may, or may not have been addressed isn't an easy task, especially for the less experienced slackers.

Thanks for the link, I will take a look at it. It might be rather technical but I want to learn.

7 OpenSSL security fixes

http://www.openssl.org/news/secadv_20140605.txt

2014 is definitely not OpenSSL year lol

Update 20140605

1. OpenSSL
   
   As BenCollver reports above, OpenSSL has issued an advisory describing seven vulnerabilities (a few of which are quite severe).
   OpenSSL recommends users immediately upgrade to one of: OpenSSL 0.9.8za, 1.0.0m, or 1.0.1h.
   
   The one getting most attention is a pretty serious potential MitM via ChangeCipherSpec injection (CVE-2014-0224). Those
   interested can read more here.
   
   A second vulnerability, related to the mishandling of invalid DTLS fragments, has received less attention likely because of DTLS's
   more limited usage. However, its impact severity is also high because successful exploitation can potentially result in remote code
   execution.
   
   OpenSSL is critical enough that I thought fellow slackers might appreciate if I shared my own build framework. I've placed
   openssl-20140605.tar.bz2 (sig) at the slackdepot which contains all the files needed to build today's releases: OpenSSL 1.0.1h
   (with OpenSSL 0.9.8za providing compatibility support).
   
   My build framework is based on Slackware 14.1's build files but I made some changes which I describe below along with my
   reasons for making them. In my framework:
   
   
   • GCC's stack protection is enabled (valuable code-hardening feature)
     
     
   • OpenSSL's custom "freelists" are disabled (wrapping malloc and related functions was one of the reasons Heartbleed went
     unnoticed for so long)
     
     
   • OpenSSL's support of SSLv2 is disabled (it's unsafe and should not be used)
     
     
   • OpenSSL's heartbeat extension support is disabled (increases the amount of code in OpenSSL's hot path - not needed)
     
     
   • IDEA and MDC2 are included (no longer under patent protection)

--mancha

3 members found this post helpful.

Nor GNUtls, unfortunately. That kinda eliminates the very foundation of Linux security (these bugs have been present for quite a while, and the coding quality is very bad). Sad. Anyway, hopefully libressl will come out soon so I can switch. I tried e-mailing the devs and recommending crowdfunding the project. No response so far.

I personally doubt that OpenBSD will crowdfund LibreSSL - they seem to prefer foundations.

Incidentally, the OpenBSD Foundation official supports LibreSSL, and there is a fundraising campaign every year. (Campaign 2014 has met its goal, but that doesn't stop anybody from donating!)