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.
Glibc 2.19, and earlier, have a vulnerability that allows directory traversal via crafted locale-related environment variables.
This is particularly worrisome when suid/sgid programs inherit these because of the possibility of arbitrary code execution
with elevated privileges. (CVE-2014-0475)
Loadable gconv transliteration modules in glibc 2.19, and earlier, have never worked properly and the implementation contains
serious security issues. A working root exploit has been made available for Fedora 20 that demonstrates the severity of this
flaw. (CVE-2014-5119)
Note: Procmail 3.22 fails to compile with recent glibc's. Here's a diff against Slackware 14.1's procmail.SlackBuild so it handles
the security patch as well as glibc conflicts:
The possibility to trigger exploitable heap-based buffer overflows in the gpgsm and uiserver engines was discovered in gpgme 1.5.0,
and earlier. (CVE-2014-3564)
Recommendation: re-build gpgme 1.4.1 after applying my backported fix (gpgme-1.4.1_CVE-2014-3564.diff) or, alternatively, upgrade
to gpgme 1.5.1.
dbus
In dbus 1.6.20, and earlier, malicious clients can make dbus-daemon disconnect a system service using a vulnerability in the
handling of sendmsg() or by sending messages with fds in rapid succession. (CVE-2014-3532 and CVE-2014-3533, respectively)
Dbus 1.6.20, and earlier, contain a potential DoS vulnerability that under certain configurations could allow unauthorized
side-channel communication between processes. (CVE-2014-3477)
As GazL alerted us in post #194, a vulnerability was discovered in the LZO algorithm (and related LZ4 algorithm) with potentially
far-reaching implications because of the large number of things that implement them (e.g. lzo, ffmpeg, python-lz4, OpenVPN, Linux
kernel, etc.). This vulnerability has had its share of controversy with researchers disagreeing over severity and exploitability.
Nevertheless, lzo 2.07 fixes the potential integer overflow condition that can trigger buffer overruns in its "safe" decompressor
variants while processing maliciously crafted data. (CVE-2014-4607)
A potential integer overflow in cdf_read_property_info was discovered in file 5.18, and earlier, that permits maliciously triggering
a DoS via specially-crafted CDF files. (CVE-2014-3587)
Recommendation: re-build file 5.14 after applying my backported fix (file-5.14_CVE-2014-3587.diff) or, alternatively, upgrade to
file 5.19.
Note: There are a couple of additional vulnerabilities in Slackware 14.1's file (CVE-2014-1943 and CVE-2014-2270). See post #96
for details and instructions on how to fix them.
subversion
Subversion 1.7.17, and earlier, improperly validate wildcards in SSL certs in ra_serf (note: only applicable if using serf).
(CVE-2014-3522)
Subversion 1.7.17, and earlier, have a vulnerability that can be exploited to cause credentials cached with svn to be sent to the
wrong server. (CVE-2014-3528)
Glibc 2.19, and earlier, have a vulnerability that allows directory traversal via crafted locale-related environment variables.
This is particularly worrisome when suid/sgid programs inherit these because of the possibility of arbitrary code execution
with elevated privileges. (CVE-2014-0475)
Loadable gconv transliteration modules in glibc 2.19, and earlier, have never worked properly and the implementation contains
serious security issues. A working root exploit has been made available for Fedora 20 that demonstrates the severity of this
flaw. (CVE-2014-5119)
2.20 has just been tagged in git, so I wouldn't bother rebuilding 2.19 for current. Decision is with Pat of course, but I expect 2.20 will turn up in current before too long.
when you upgrade subversion 1.7.18, you might need to upgrade neon as well to latest 0.30.0 however I think there is typo in ./src/ne_openssl.c
for people disabled sslv2
Does the backported glibc-fixes apply to 2.19 in -current as well?
Hi Mats. Not without a bit of tweaking to the Makefile changes and some offsets (though my CVE-2014-5119 diff might apply more
cleanly because it only patches long-standing code). However, my patches have source attribution in their headers and in the case
of glibc patches I list the upstream commits I used to construct them.
By the way, glibc 2.20 (sig), which includes those fixes, was released today.
Quote:
Originally Posted by number22
when you upgrade subversion 1.7.18, you might need to upgrade neon as well to latest 0.30.0 however I think there is typo in ./src/ne_openssl.c for people disabled sslv2
Hi number22. You're right, if your OpenSSL is built without SSLv2 support (which I believe a very wise decision; see post #163),
you need to update neon or rebuild Slackware 14.1's neon 0.29.6 after applying neon-0.29_disable-SSLv2.diff.
--mancha
Last edited by mancha; 09-16-2014 at 09:47 PM.
Reason: no need to define macro
Hi Mats. Not without a bit of tweaking to the Makefile changes and some offsets (though my CVE-2014-5119 diff might apply more
cleanly because it only patches long-standing code). However, my patches have source attribution in their headers and in the case of glibc patches I list the upstream commits I used to construct them.
By the way, glibc 2.20 (sig), which includes those fixes, was released today.
Ok, compiling glibc 2.20 halts when applying patches. Do you know which patches are necessary to build 2.20?
Mats
Last edited by mats_b_tegner; 09-08-2014 at 05:14 AM.
Slackware 13.0-14.1 addressed CVE-2013-4576 in GnuPG-1 when it upgraded to GnuPG 1.4.16 on 20131220. However, Slackware's
GnuPG-2 remains vulnerable because Libgcrypt (which underlies GnuPG-2) wasn't updated.
I mentioned this in post #1 and back then my recommendation was to upgrade to Libgcrypt 1.6.0. Since writing that post, fixes have
been backported to the 1.5.x branch - specifically, they are included in Libgcrypt 1.5.4 (see: announcement).
Recommendation (revised): Upgrade to Libgcrypt 1.5.4 (sig) or, alternatively, upgrade to Libgcrypt 1.6.2 (sig). The latter requires
rebuilding GnuPG-2.
Note: An additional CVE-2014-5270 has been assigned to a method of exploiting the vulnerable code by touching exposed metal
(CVE-2013-4576 applies to acoustic attacks). Those interested can read this neat description.
ppp
It was announced a security vulnerability in which a potential integer overflow during option parsing can be exploited to overwrite the
heap was discovered in ppp 2.4.6, and earlier. (CVE-2014-3158)
Regarding the glibc vulnerabilities I recently described in post #200 (CVE-2014-0475 & CVE-2014-5119), I've prepared the following
patches against glibc 2.19 for the benefit of Slackware-current users:
Mancha, I went to try your two proof of concepts from here. I run them both, the one for CVE-2012-4412 gives me a segmentation fault and the second one works (in a few seconds I get an overflow).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.