[Slackware security] vulnerabilities outstanding 20140101

metaschima · 04-21-2014, 11:27 AM

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

Mercury305 · 04-21-2014, 12:52 PM

I would say add mancha to the slackware core team.

number22 · 04-25-2014, 03:37 PM

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.

mancha · 04-29-2014, 12:41 PM

Update 20140429

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.

mancha · 05-15-2014, 06:27 AM

Update 20140515

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.

fskmh · 05-15-2014, 02:13 PM

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.

GazL · 05-16-2014, 03:45 AM

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/

willysr · 05-16-2014, 04:10 AM

.30 was released for current system before it was upgraded to 3.14.3 and now to 3.14.4

tuxbg · 05-16-2014, 04:32 AM

Kernel 3.10.40 fix that security issue

GazL · 05-16-2014, 04:53 AM

Quote:

Originally Posted by willysr

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

phenixia2003 · 05-16-2014, 04:56 AM

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

fskmh · 05-16-2014, 12:34 PM

Quote:

Originally Posted by GazL

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.

mancha · 05-16-2014, 12:37 PM

Quote:

Originally Posted by fskmh

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

fskmh · 05-16-2014, 12:42 PM

Quote:

Originally Posted by mancha

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.

mancha · 05-16-2014, 01:05 PM

Quote:

Originally Posted by fskmh

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