LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 02-06-2014, 12:43 PM   #61
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,982

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492

Quote:
Originally Posted by angryfirelord View Post
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.
 
Old 02-06-2014, 12:47 PM   #62
angryfirelord
Member
 
Registered: Dec 2005
Distribution: Fedora, CentOS
Posts: 515

Rep: Reputation: 66
Quote:
Originally Posted by metaschima View Post
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.
Thanks. That's what I figured.
 
Old 02-06-2014, 06:24 PM   #63
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by angryfirelord View Post
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:

Code:
CVE-2013-2929   CVE-2013-2930   CVE-2013-4270   CVE-2013-4348
CVE-2013-4470   CVE-2013-4511   CVE-2013-4512   CVE-2013-4513
CVE-2013-4514   CVE-2013-4515   CVE-2013-4516   CVE-2013-4563
CVE-2013-4579   CVE-2013-4587   CVE-2013-6367   CVE-2013-6368
CVE-2013-6376   CVE-2013-6378   CVE-2013-6380   CVE-2013-6381
CVE-2013-6382   CVE-2013-6383   CVE-2013-6431   CVE-2013-6432
CVE-2013-6763   CVE-2013-7026   CVE-2013-7027   CVE-2013-7263
CVE-2013-7264   CVE-2013-7265   CVE-2013-7266   CVE-2013-7267
CVE-2013-7268   CVE-2013-7269   CVE-2013-7270   CVE-2013-7271
CVE-2013-7281   CVE-2014-0038   CVE-2014-1438   CVE-2014-1444
CVE-2014-1445   CVE-2014-1446
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
 
12 members found this post helpful.
Old 02-07-2014, 03:19 AM   #64
ponce
LQ Guru
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 7,060

Rep: Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139
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.

Last edited by ponce; 02-07-2014 at 05:50 AM.
 
1 members found this post helpful.
Old 02-07-2014, 12:32 PM   #65
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,982

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
Yeah, kernel update can break things quite easily, so I'm betting that's why they aren't pushed unless it is a critical vulnerability.
 
Old 02-07-2014, 12:58 PM   #66
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Update 20140207
  1. stunnel 4.56

    CVE-2013-1762 fixed (fixed in 4.55)

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

Last edited by mancha; 02-07-2014 at 01:29 PM.
 
1 members found this post helpful.
Old 02-09-2014, 01:43 PM   #67
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Update 20140209
  1. 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.
 
1 members found this post helpful.
Old 02-11-2014, 09:27 AM   #68
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Update 20140211
  1. 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).

    Issue originally reported by BrZ (see: http://www.linuxquestions.org/questi...0/#post5048482).

  2. mariadb

    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
 
1 members found this post helpful.
Old 02-11-2014, 09:32 AM   #69
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by ponce View Post
...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):
  1. rebuild 3.10.17 after applying upstream fix
  2. rebuild 3.10.17 with CONFIG_X86_X32 disabled
I'm actually surprised Slackware hasn't addressed this yet. Ponce, what are your thoughts on that?

--mancha
 
1 members found this post helpful.
Old 02-11-2014, 09:42 AM   #70
ponce
LQ Guru
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 7,060

Rep: Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139
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).
 
Old 02-11-2014, 10:10 AM   #71
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by ponce View Post
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?
 
1 members found this post helpful.
Old 02-11-2014, 10:20 AM   #72
ponce
LQ Guru
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 7,060

Rep: Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139
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 View Post
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.

Last edited by ponce; 02-11-2014 at 10:23 AM.
 
2 members found this post helpful.
Old 02-11-2014, 12:16 PM   #73
mancha
Member
 
Registered: Aug 2012
Posts: 484

Original Poster
Rep: Reputation: Disabled
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
 
1 members found this post helpful.
Old 02-11-2014, 12:40 PM   #74
ponce
LQ Guru
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 7,060

Rep: Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139
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
 
Old 02-11-2014, 01:03 PM   #75
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,982

Rep: Reputation: 492Reputation: 492Reputation: 492Reputation: 492Reputation: 492
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.
 
1 members found this post helpful.
  


Reply

Tags
exploit, security, slackware


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[Slackware Security]: Some pending vulnerabilities... mancha Slackware 7 08-22-2013 09:08 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 02:38 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration