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.
I apologize if this is slightly off topic and/or has been asked before, but is there a risk with running the 3.10.17 kernel when the latest upstream longterm release is 3.10.28? Are most of the fixes simply bug fixes or do the kernel security patches not really affect Slackware?
I run the latest upstream LTS kernel. However, most of the fixes are bug fixes. In the recent case of the kernel vulnerability, it is a security fix.
I apologize if this is slightly off topic and/or has been asked before, but is there a risk with running the 3.10.17 kernel when the latest upstream longterm release is 3.10.28? Are most of the fixes simply bug fixes or do the kernel security patches not really affect Slackware?
Long-term support (LTS) kernels, for a period of at least two years, admit patches which address:
security issues and other bugs
notable performance or interactivity issues
new HW IDs and quirks
Many bug-fixes in LTS kernel trees specifically address security issues; Others do not.
To give you a sense of magnitude of risk exposure, I've put together a partial list of vulnerabilities present in kernel 3.10.17:
The list's size might initially frighten so it's important to point out these issues vary in severity level; differing in access vectors,
ease of exploitation, impact (e.g. DoS, information disclosure, privilege escalation, etc.), among other characteristics. In other
words, some of the above occur only under uncommon configurations/circumstances and/or are of relatively low-impact.
It is also important to be aware not all of the above affect Slackware 14.1/current.
For example, CVE-2013-7271 doesn't because Slackware 14.1/current kernels don't ship with CCITT X.25 packet layer support.
On the other hand, the recent high-profile x32 ABI vulnerability that can be leveraged to gain root privileges (CVE-2014-0038)
does affect Slackware 14.1/current on 64-bit platforms. The severity of that particular vulnerability drove me to author a
counter-measure kernel module which I shared with the entire Linux community the day an exploit was made public (see earlier
posts in this thread for details). [NEWS: 3.10.29 released 4 hours ago contains a fix]
Judging from the relative infrequency with which Slackware has issued kernel upgrades for stable releases in the recent past
(3 times in the last five years by my count), I conclude kernel vulnerabilities need to be particularly severe to trigger a Slackware
update. On this point, it would be instructive (for me anyways) to hear directly from Pat on how he decides when to push new
kernel packages.
I hope this answers your question and is valuable to other members of the Slackware community who might have been wondering
similar things.
--mancha
Last edited by mancha; 02-06-2014 at 10:24 PM.
Reason: improve readability
I remember the last time that a kernel security update for stable was pushed (just a few months ago): it was for 14.0, from 3.2.29 to 3.2.45, to fix a local root problem, but it had some regressions for intel graphics chipsets that forced Pat to build and release it three times (and luckily the regressions got fixed in the end).
so I can understand at least one reason why kernel updates are so delicate: while they may fix security issues, you can never be sure that nasty regressions hasn't been introduced.
A vulnerability in NTLM authentication as can be used by CONNECT tunnels allows a malicious proxy server (or adversary able to MITM
stunnel-proxy connection) to execute arbitrary code on the system running the vulnerable stunnel. Note: Only affects 64-bit platforms.
poppler
A flaw (CVE-2013-7296) in JBIG2Stream::readSegments, introduced in Poppler version 0.19.0, allows
remote attackers to cause a DoS (segmentation fault) or other unknown impacts via a crafted PDF.
Solution: Upgrade to Poppler 0.24.5 or rebuild earlier versions after applying fix.
ɐɥɔuɐɯ--
Last edited by mancha; 02-18-2014 at 10:24 AM.
Reason: Flesh out description.
icu4c
A use-after-free vulnerability (CVE-2013-2924) in International Components for Unicode (icu4c) allows remote attackers
to cause a DoS or, potentially, trigger other effects.
Solution: apply my backport fix to icu4c 51-2 (note: this is fixed in icu4c 52-1 but upgrading breaks API).
An overflow in client/mysql.cc (CVE-2014-0001) allows a malicious database server to cause a DoS and potentially execute
arbitrary code on vulnerable clients.
Solution: upgrade to mariadb 5.5.35.
--mancha
Last edited by mancha; 02-18-2014 at 10:38 AM.
Reason: add icu4c vuln. description
...while [kernel upgrades] may fix security issues, you can never be sure that nasty regressions hasn't been introduced.
Fortunately for CVE-2014-0038 (w/ confirmed root exploit on Slackware64 14.1+), Pat has a couple of simple & low-risk solutions
available to him (other than upgrading to 3.10.29):
I think there's no hurry: whoever considered this urgent, already had the time to rebuild a patched kernel himself.
Fixing stuff to redistribute takes the time it takes: check other distro response time and multiply it for the number of maintainers there (here we have one).
I think there's no hurry: whoever considered this urgent, already had the time to rebuild a patched kernel himself.
Root exploits are urgent and are likely considered so my most. I'm confused though. A few posts ago you justified the delay
by saying kernel upgrades are tricky (even for experienced hands like Pat). Now you endorse users doing this themselves?
please mancha, read what I wrote that is not exactly what you are reporting (I added a bold in the quote)
Quote:
Originally Posted by ponce
so I can understand at least one reason why kernel updates are so delicate: while they may fix security issues, you can never be sure that nasty regressions hasn't been introduced.
I said that, in my opinion (implied), one reason could be that you cannot never test kernel upgrades enough to be sure that there aren't any regressions...
I'm not Pat and I have no idea what he thinks.
plus, I personally have always endorsed users doing stuff themselves: the Slackware user, still in my opinion, shouldn't be someone waiting for baby food with an open mouth.
We're not going to agree but thanks for the lively discussion.
I think Slackware users benefit from hearing different perspectives and making up their own minds.
--mancha
PS On your last objection, it's fair to say your comments implicitly sought to justify the situation (e.g. new kernels can introduce regressions;
root exploits aren't urgent; users can always upgrade things themselves; Slackware's security team is small).
But, it is logically inconsistent for you to use the complexity of kernel upgrades as possible rationale for Slackware's delay while in the next
breath suggest users can upgrade themselves if the delay worries them. Mandibular habits, notwithstanding.
Last edited by mancha; 02-11-2014 at 12:22 PM.
Reason: line wraps
but I never said that upgrading a kernel is complex, please read again my previous answer (actually it isn't at all, it's one of the first things I learned on Linux, more than 16 years ago)
if you prefer to hear it in a really short phrase, I said that it's risky: take last time, when inexperienced users with some intel hardware after the upgrade found theirselves in front of a black screen.
but if you are an administrator of a multiuser box and you're concerned about the exploit, you can choose what risk to take and you should be able also to build an updated/patched one yourself: if you aren't able to do it maybe you shouldn't administer a multiuser box at all.
if you're not an administrator of a multiuser box the exploit won't hit you.
and remember that you asked for my opinion (oh well, I learned for the next time)
Last edited by ponce; 02-12-2014 at 12:22 AM.
Reason: engrish, sorre
I don't see any point in arguing about it. mancha has submitted a proof of concept that works, so I really do hope Pat V. at least disables x32 and pushes an update. It doesn't affect me, because I run a custom latest LTS kernel.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.