LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   [Slackware security] vulnerabilities outstanding 20140101 (https://www.linuxquestions.org/questions/slackware-14/%5Bslackware-security%5D-vulnerabilities-outstanding-20140101-a-4175489800/)

metaschima 02-06-2014 12:43 PM

Quote:

Originally Posted by angryfirelord (Post 5112715)
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.

angryfirelord 02-06-2014 12:47 PM

Quote:

Originally Posted by metaschima (Post 5112858)
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.

mancha 02-06-2014 06:24 PM

Quote:

Originally Posted by angryfirelord (Post 5112715)
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

ponce 02-07-2014 03:19 AM

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.

metaschima 02-07-2014 12:32 PM

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.

mancha 02-07-2014 12:58 PM

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

mancha 02-09-2014 01:43 PM

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ɐɯ--

mancha 02-11-2014 09:27 AM

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

mancha 02-11-2014 09:32 AM

Quote:

Originally Posted by ponce (Post 5113171)
...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

ponce 02-11-2014 09:42 AM

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

mancha 02-11-2014 10:10 AM

Quote:

Originally Posted by ponce (Post 5115598)
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?

ponce 02-11-2014 10:20 AM

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 (Post 5113171)
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.

mancha 02-11-2014 12:16 PM

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.

ponce 02-11-2014 12:40 PM

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)

metaschima 02-11-2014 01:03 PM

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.


All times are GMT -5. The time now is 05:55 PM.