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.
A security audit of GnuTLS, carried out by one of its primary developers, has identified serious flaws in its certificate validation
code (CVE-2014-0092). The vulnerabilities can be exploited via specially-crafted certificates to effectively circumvent certificate
validation checks.
Solution: Slackware deployed security fixes for Slackware 13.0 through current the day the issue became public (20140303).
I encourage those who've not yet applied these updates to do so as soon as possible.
Note: Slackware 12.1 and 12.2 systems can address this issue by rebuilding GnuTLS after applying Slackware 13.0's fix.
--mancha
So what slackware code is actually using GnuTLS?
I did a search of the current slackware64-current/source and found very little.
It looks like two packages use it as they are built with "gnutls"
l/loudmouth a library for the Jabber instant messenger protocol.
xap/pan a usenet news reader.
Since I don't use Jabber and I don't use pan this appears to be an extremely low impact "security risk".
Gnome and CUPS, http://en.wikipedia.org/wiki/GnuTLS some of KDE, Apache and Wine may using it, GnuTLS project is very "precarious suspicious". It should drop Gnu from its name.
A flaw in the way udisks/udisks2 processes path names (CVE-2014-0004) can be exploited by malicious local users, via
specially-crafted directory structures, to execute arbitrary code as the udisks daemon (i.e. root).
A buffer overflow vulnerability (CVE-2014-0467) was discovered in mutt's parsing of RFC2049 headers. A remote attacker
can exploit this via an email with specially-crafted headers to cause a DoS and potentially execute arbitrary code.
An internal samba audit has identified two security issues:
CVE-2013-4496 (flaw allows bypass of password lock-out and unlimited password attempts via the samr interface).
CVE-2013-6442 (flaw in smbacls potentially clears an object's existing ACLs leaving it unprotected).
My Slackware deployments do not require a tin foil hat the size of a sombrero, but I also am very grateful to mancha for the investigation and fixes to security issues. It shows an ability beyond my ken.
On the file issue, it just goes to show the degree of difficulty that our BDFL faces in balancing usability with security. An upstream change made the basic nano utility segfault without a change to file to use a compiled magic file. http://www.linuxquestions.org/questi...le-4175455374/ Now a security issue has been uncovered.
Yeah, stability and security have to be juggled carefully as they can affect one another. I'm only concerned about critical exploits, like privilege escalation / remotely rooting the system, etc. Lesser exploits are more of a concern on multi-user systems or for sysadmins, not me.
I want too commend 'Mancha' along with other Slackers for contributing helpful information to the Slackware community here at LQ.
Thanks for your post and thanks to other slackers who have encouraged me in this thread and privately. It makes the effort worthwhile
knowing folks are appreciative and finding the information valuable.
To slackers contributing alerts or solutions here, keep up the good work.
In order to compile FreeType 2.5.3 Harfbuzz needs to be updated as well.
FreeType
Mats, thanks for bringing this up. Actually, HarfBuzz is a new and optional dependency of FreeType as of 2.5.3.
FreeType 2.5.3 will build on stock Slackware 14.1 but automatically disables HarfBuzz support when it doesn't
detect a new enough version.
However, building FreeType 2.5.3 requires a modified illadvisederror patch (see note at end), so I've amended my
recommendation for most slackers:
Solution: Rebuild Slackware 14.1 FreeType 2.5.0.1 after applying my CVE-2014-2240+CVE-2014-2241 backport fix (sig).
--mancha
Note: For those wishing to upgrade to FreeType 2.5.3:
Get my FreeType 2.5.3 illadvisederror patch (gzip it or edit the Slackbuild so it applies uncompressed)
Build FreeType 2.5.3 (1st pass with no HarfBuzz support)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.