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 04-21-2014, 12:27 PM   #136
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,526

Rep: Reputation: Disabled

Race condition in the mac80211 subsystem in the Linux kernel before 3.13.7 allows remote attackers to cause a denial of service (system crash) via network traffic that improperly interacts with the WLAN_STA_PS_STA state (aka power-save mode), related to sta_info.c and tx.c.
http://web.nvd.nist.gov/view/vuln/de...=CVE-2014-2706
https://github.com/torvalds/linux/co...22168658e613ba
 
Old 04-21-2014, 01:52 PM   #137
Mercury305
Member
 
Registered: Jul 2012
Location: Rockville, MD
Distribution: CrunchBang / Ubuntu
Posts: 540

Rep: Reputation: Disabled
I would say add mancha to the slackware core team.
 
3 members found this post helpful.
Old 04-25-2014, 04:37 PM   #138
number22
Member
 
Registered: Sep 2006
Location: Earth
Distribution: Slackware 14.1 Slackware64-current multilib
Posts: 208
Blog Entries: 2

Rep: Reputation: Disabled
isc dhcp listens on random ipv6 udp port, -4 flag is used to explicitly disable ipv6 protocol, this bug has been years, wondering why isc can't fix it promptly.

Last edited by number22; 04-25-2014 at 04:42 PM.
 
1 members found this post helpful.
Old 04-29-2014, 01:41 PM   #139
mancha
Member
 
Registered: Aug 2012
Posts: 362

Original Poster
Rep: Reputation: Disabled
Update 20140429
  1. PHP

    PHP's FastCGI Process Manager (i.e. php-fpm) uses insecure defaults on UNIX sockets. This can potentially result in local
    users, with the capability to connect to UNIX sockets, being able to gain elevated privileges (CVE-2014-0185).

    Solution(s):
    • Re-build PHP 5.4.27 with my repackaging of upstream's fix.
      or
    • Upgrade to PHP 5.4.28 which is planned for release in early May.
--mancha

========

Update #1


PHP 5.4.28 has released. Users are encouraged to upgrade.

Last edited by mancha; 05-02-2014 at 10:12 AM. Reason: announce 5.4.28
 
Old 05-15-2014, 07:27 AM   #140
mancha
Member
 
Registered: Aug 2012
Posts: 362

Original Poster
Rep: Reputation: Disabled
Update 20140515
  1. libXfont

    Several vulnerabilities have been identified in libXfont:

    • CVE-2014-0209: integer overflow of allocations in font metadata file parsing
    • CVE-2014-0210: unvalidated length fields when parsing xfs protocol replies
    • CVE-2014-0211: integer overflows calculating memory needs for xfs replies

    Two of these require an active X font server in the font path to be exploitable (not a Slackware default) but the third affects
    Slackware in its default state.

    Solution: These issues are expected to be resolved in libXfont 1.4.8; users who prefer not waiting can re-build libXfont 1.4.7
    with my upstream-based patch: libXfont-1.4.7-CVE-2014-0209_0210_0211.diff (sig).

    Detailed Solution: For those not comfortable compiling X components, here's an easy step-by-step:

    1. Download the libXfont build directory from Slackware 14.1's patches directory (32-bit or 64-bit)
    2. Create a sub-directory in the patch directory called "libXfont" and put libXfont-1.4.7-CVE-2014-0209_0210_0211.diff there.
    3. Create a file in the patch directory called "libXfont.patch" with the following line:
      Code:
      cat $CWD/patch/libXfont/libXfont-1.4.7-CVE-2014-0209_0210_0211.diff | patch -p1 --verbose || { touch /.failed ; continue ; }
    4. Edit build/libXfont and change the tag from "1_slack14.1" to "1_slack14.1_mancha" to distinguish from official Slackware.
    5. Rebuild by running libXfont.SlackBuild and then upgradepkg.

    Note: Other Slackware versions are also vulnerable but these instructions were developed for Slackware 14.1.
--mancha

========

Update #1

Upstream has released libXfont 1.4.8 which includes fixes for the issues described above.

Last edited by mancha; 05-17-2014 at 09:39 AM.
 
Old 05-15-2014, 03:13 PM   #141
fskmh
Member
 
Registered: Jun 2002
Location: South Africa
Distribution: Slackware64-current multilib
Posts: 236

Rep: Reputation: 55
cve-2014-0196

Quote:
Vulnerability Summary for CVE-2014-0196
Original release date: 05/07/2014
Last revised: 05/12/2014
Source: US-CERT/NIST
Overview

The n_tty_write function in drivers/tty/n_tty.c in the Linux kernel through 3.14.3 does not properly manage tty driver access in the "LECHO & !OPOST" case, which allows local users to cause a denial of service (memory corruption and system crash) or gain privileges by triggering a race condition involving read and write operations with long strings.
Impact
CVSS Severity (version 2.0):
CVSS v2 Base Score: 6.9 (HIGH) (AV:L/AC:M/AU:N/C:C/I:C/A:C) (legend)
Impact Subscore: 10.0
Exploitability Subscore: 3.4
CVSS Version 2 Metrics:
Access Vector: Locally exploitable
Access Complexity: Medium
Authentication: Not required to exploit
Impact Type: Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service
It appears that kernels from 2.6.31-rc3 to 3.14.3 are vulnerable. Just read through the ChangeLog for 3.14.4 and it seems the issue was addressed in that update. I tried this PoC here on Slack64-14.1 with 3.13.9 and 3.14.2 and it didn't work but I haven't tried it on the stock 3.10.30 kernel.
 
1 members found this post helpful.
Old 05-16-2014, 04:45 AM   #142
GazL
Senior Member
 
Registered: May 2008
Posts: 3,503

Rep: Reputation: 1025Reputation: 1025Reputation: 1025Reputation: 1025Reputation: 1025Reputation: 1025Reputation: 1025Reputation: 1025
I can't test the PoC here as I've already updated to .40 because of this, but the description does mention priv-escalation via a race condition. Perhaps the exploit is losing the race on your system for some reason. However, in order to remain safe you have to win every time; the exploit merely needs to win once; so, worth patching regardless.

BTW, where did ".30" come from? I thought 3.10.17 was the latest kernel in patches/
 
Old 05-16-2014, 05:10 AM   #143
willysr
Senior Member
 
Registered: Jul 2004
Location: Jogja, Indonesia
Distribution: Slackware-Current
Posts: 2,621

Rep: Reputation: 445Reputation: 445Reputation: 445Reputation: 445Reputation: 445
.30 was released for current system before it was upgraded to 3.14.3 and now to 3.14.4
 
1 members found this post helpful.
Old 05-16-2014, 05:32 AM   #144
tuxbg
Member
 
Registered: Sep 2012
Location: Bulgaria,Varna
Distribution: Slackware64
Posts: 249

Rep: Reputation: Disabled
Kernel 3.10.40 fix that security issue
 
Old 05-16-2014, 05:53 AM   #145
GazL
Senior Member
 
Registered: May 2008
Posts: 3,503

Rep: Reputation: 1025Reputation: 1025Reputation: 1025Reputation: 1025Reputation: 1025Reputation: 1025Reputation: 1025Reputation: 1025
Quote:
Originally Posted by willysr View Post
.30 was released for current system before it was upgraded to 3.14.3 and now to 3.14.4
Ahh, ok, that makes sense now. Thanks.
With the low activity rate so far this cycle, I've not been paying much attention to the goings on in '-current'.
 
Old 05-16-2014, 05:56 AM   #146
phenixia2003
Member
 
Registered: May 2006
Location: France
Distribution: Slackware
Posts: 299

Rep: Reputation: 179Reputation: 179
Hello,

As tuxbg said, 3.10.40 solves this issue but the 3.10 branch (since .39) includes this commit which seems to introduce some troubles on x86_64 as stated here.

--
SeB

Last edited by phenixia2003; 05-16-2014 at 06:02 AM.
 
Old 05-16-2014, 01:34 PM   #147
fskmh
Member
 
Registered: Jun 2002
Location: South Africa
Distribution: Slackware64-current multilib
Posts: 236

Rep: Reputation: 55
Quote:
Originally Posted by GazL View Post
I can't test the PoC here as I've already updated to .40 because of this, but the description does mention priv-escalation via a race condition. Perhaps the exploit is losing the race on your system for some reason. However, in order to remain safe you have to win every time; the exploit merely needs to win once; so, worth patching regardless.

BTW, where did ".30" come from? I thought 3.10.17 was the latest kernel in patches/
As willysr mentioned, there was an update to .30 a while back. I usually keep a stock kernel as a boot option to go with whatever new kernel I'm running. BTW, ran the PoC on my PC at work today (3.14.2) and I got a root shell 2 out of 3 attempts (the 3rd I got a kernel panic) so this thing is definitely an issue.

Last edited by fskmh; 05-16-2014 at 01:35 PM.
 
1 members found this post helpful.
Old 05-16-2014, 01:37 PM   #148
mancha
Member
 
Registered: Aug 2012
Posts: 362

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by fskmh View Post
It appears that kernels from 2.6.31-rc3 to 3.14.3 are vulnerable. Just read through the ChangeLog for 3.14.4 and it seems the issue was addressed in that update. I tried this PoC here on Slack64-14.1 with 3.13.9 and 3.14.2 and it didn't work but I haven't tried it on the stock 3.10.30 kernel.
When this first became public I ran my own tests on Slackware 14.1 and was unable to trigger an exploitable race. After digging
through some kernel code, I concluded kernels 3.5 through 3.11 (inclusive) are not vulnerable because of concurrency control
across tty buffer allocation & population.

In addition, Slackware-current is not vulnerable thanks to a fix introduced in 3.14.4 to address this specific issue.

I've not gone back to review my analysis but at least initially I did not believe 14.1 vulnerable.

--mancha
 
2 members found this post helpful.
Old 05-16-2014, 01:42 PM   #149
fskmh
Member
 
Registered: Jun 2002
Location: South Africa
Distribution: Slackware64-current multilib
Posts: 236

Rep: Reputation: 55
Quote:
Originally Posted by mancha View Post
After digging through some kernel code, I concluded kernels 3.5 through 3.11 (inclusive) are not vulnerable because of concurrency control across tty buffer allocation & population.
Yes, I'm starting to think some kernels in between are less prone. I'm running the PoC on my home PC now (3.13.9) again and nothing's happening.
 
Old 05-16-2014, 02:05 PM   #150
mancha
Member
 
Registered: Aug 2012
Posts: 362

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by fskmh View Post
Yes, I'm starting to think some kernels in between are less prone. I'm running the PoC on my home PC now (3.13.9) again and nothing's happening.
If you're running Daley's PoC, it won't work on 3.13.9 because his exploit methodology requires tty character data to extend
through the tail of the buffer. 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.

--mancha

Last edited by mancha; 05-16-2014 at 02:12 PM.
 
  


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 10:08 AM


All times are GMT -5. The time now is 03:10 PM.

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
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration