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.
And here I was thinking SSL 2.0 was "an obsolete and insecure protocol", seems like SSL 3.0 is exactly the same. I think TLS 1.0 is close, because according to wiki
Quote:
TLS 1.0 was first defined in RFC 2246 in January 1999 as an upgrade of SSL Version 3.0. As stated in the RFC, "the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0." TLS 1.0 does include a means by which a TLS implementation can downgrade the connection to SSL 3.0, thus weakening security.[14]:1–2
To anyone going to rebuild Vim, it is a good opportunity to apply all official patches to vim 7.4 (400+ patches). Even if they are not all security updates it doesn't hurt to apply them. Slackware ships Vim with the PATCHLEVEL = 50 (50 patches applied).
You can find all of them here. There are 481 patches.
Then you cd to the directory, and gzip all files with:
Code:
$ gzip *
Then you move all the gzipped files to the "patches" directory (under vim SlackBuild's directory). The script will pick all the gzipped files and apply them automatically.
To be honest, I thought things were going to be the opposite: this thread would be for reports and the other one just for updating the status in the OP.
To be honest, I thought things were going to be the opposite: this thread would be for reports and the other one just for updating the status in the OP.
Fair enough. That makes sense. This thread can continue as is and the other thread will be used to publish status updates.
A flaw was discovered in posix_spawn_file_actions_addopen() which can be exploited via use-after-free situations or other exploitable
situations with mutated paths (CVE-2014-4043).
Solution for Slackware 14.1: Re-build glibc 2.17 with my backport of upstream's fix.
Note: If re-building glibc, I recommend the application of additional security fixes that have not been incorporated into Slackware:
CVE-2012-4424, CVE-2012-4412, CVE-2013-4237, CVE-2013-4788, and CVE-2013-4458. See this thread for details and links to my
backported fixes.
This can be accomplished by getting all the diffs and adding the following lines (in red) to the end of glibc.SlackBuild's
apply_patches() function:
TCP_Wrapper library has wrong sonames. links are messed up. need to rename.
First off, if you follow the instructions in post #266 this won't be an issue because OpenSSH 6.7p1 will link libwrap.a (as Slackware's
OpenSSH has done up through 6.6p1).
However, you're right about Slackware's tcp_wrappers package not properly building the shared library due to a broken patch it ships.
I think I emailed Pat or RW (or maybe both) several years ago with the fix.
The easiest way to correct is some sed in the Slackbuild:
I am using glibc 2.19, which patches should I apply to fix all vulnerabilities?
Relevant portions of glibc.SlackBuild for glibc 2.17 and 2.19 (below) show the patches needed (in red) and the order they should be applied.
In addition to CVE fixes, I'm recommending a hardening patch (projectzero off-by-one glibc root exploit writer said it would have made it
difficult, if not impossible, to develop his exploit with this hardening in place).
Also, I recommend those on glibc 2.17 apply a bugfix patch that fixes an issue where gcc 4.8+ during optimization can transform loops into
memset/memmove calls resulting in unexpected PLT calls to glibc (glibc 2.19 already has this fix so no patch needed there).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.