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.
Prior to 3.14rc1, flag data followed character data. This doesn't prove 3.13.9 is safe, just that Daley's PoC is not effective on it.
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.
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:
Code:
KERNEL(S) CVE-2014-0196 STATUS
-------------------- ---------------------------
2.6.31 - 3.2.58 VULNERABLE
3.2.59 NOT VULNERABLE
3.3 - 3.4.90 VULNERABLE
3.4.91 NOT VULNERABLE
3.5 - 3.8.13 NOT VULNERABLE [see: post below]
3.9 - 3.10.39 VULNERABLE
3.10.40 NOT VULNERABLE
3.11 - 3.12.19 VULNERABLE
3.12.20 NOT VULNERABLE
3.13 - 3.14.3 VULNERABLE
3.14.4 NOT VULNERABLE
3.15rc1 - 3.15rc4 VULNERABLE
3.15rc5 NOT VULNERABLE
--mancha
Last edited by mancha; 05-19-2014 at 10:05 AM.
Reason: Update status table
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).
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)
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)
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).
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:
Quote:
PHP 5.4.29 Released
The PHP development team announces the immediate availability of PHP 5.4.29. 16 bugs were fixed in this release, including two security issues in fileinfo extension. All PHP 5.4 users are encouraged to upgrade to this version.
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.
Last edited by GazL; 06-04-2014 at 07:44 AM.
Reason: removed incorrect info. Why is there no strikethrough option :(
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
Last edited by mancha; 06-05-2014 at 08:23 PM.
Reason: add link / cleanup
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.
Last edited by metaschima; 06-05-2014 at 05:17 PM.
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!)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.