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.
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.
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 09:12 AM.
Reason: announce 5.4.28
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:
Download the libXfont build directory from Slackware 14.1's patches directory (32-bit or 64-bit)
Create a sub-directory in the patch directory called "libXfont" and put libXfont-1.4.7-CVE-2014-0209_0210_0211.diff there.
Create a file in the patch directory called "libXfont.patch" with the following line:
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.
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/
.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'.
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.
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.