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"

1. l/loudmouth a library for the Jabber instant messenger protocol.
2. 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.

Most of the Slackware packages seem to use OpenSSL instead of GnuTLS.

Gnome is not included in the standard release of Slackware.

CUPS specifically ignores GnuTLS as the build script contains this parameter:
"--enable-gnutls=no"

I didn't see GnuTLS in the Slackware KDE or Apache packages.

Wine, like Gnome is not included in the standard release.

This may find some but maybe not all if the library is loaded with dlopen:

guanx, thanks, you beat me to it. yeah, simple bash script can easy tell:
another example code
apparently samba uses libgnutls too, didn't know it before.

Update 20140314

1. libssh
   
   A problem with how libssh handles prng states for forked sshd's (CVE-2014-0017) has been fixed upstream.
   
   Solution: Rebuild libssh 0.5.4 (or 0.5.5) after applying upstream fix.
   
   
2. file
   
   Two security issues were identified with libmagic (file package):
   
   CVE-2014-1943 (infinite recursion flaw)
   CVE-2014-2270 (improper bounds checking)
   
   Solution: Rebuild file 5.14 after applying my backport fixes:
   
   file-5.14_CVE-2014-1943.diff
   file-5.14_CVE-2014-2270.diff
   Note: should be applied in above order.
   
   PoC for CVE-2014-1943:
   
   Code:

   ---

   $ echo -n "4552000000" | xxd -r -p | file -

   ---

3. php
   
   The above libmagic security issues affect Slackware's PHP package because PHP bundles libmagic for its fileinfo extension.
   
   Solution: Rebuild PHP 5.4.24 (or PHP 5.4.25) after applying my backport fixes:
   
   php-5.4.24_CVE-2014-1943.diff
   php-5.4.24_CVE-2014-2270.diff
   Note: should be applied in above order.
   
   PoC for CVE-2014-1943:
   
   Code:

   ---

   <?php
/* CVE-2014-1943 */
$finfo = new finfo(FILEINFO_MIME);
$hex = hex2bin("4552000000");
return $finfo->buffer($hex);
?>

   ---

4. FreeType
   
   Two security issues have been identified in FreeType's CFF driver:
   
   CVE-2014-2240 (out-of-bounds stack read/write)
   CVE-2014-2241 (denial of service via triggerable assertion)
   
   Solution: Upgrade to FreeType 2.5.3.
   
   
5. udisks & udisks2
   
   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).
   
   Solution: Apply Slackware's security update from 20140311.
   
   
6. mutt
   
   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.
   
   Solution: Apply Slackware's security update from 20140312.
   
   
7. samba
   
   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).
   
   Solution: Apply Slackware's security update from 20140313.

--mancha

Member Response
 

Hi,

I want too commend 'Mancha' along with other Slackers for contributing helpful information to the Slackware community here at LQ.

I'm sure PV & team appreciates the endeavors of all for providing additional security assistance.

Read the entire thread and found a lot of useful information.

Thanks to all!
:hattip:

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.

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.

--mancha

This has been fixed in 5.4.26 which has just been released
http://www.php.net/ChangeLog-5.php#5.4.26

This thread is great, I think OP is doing a job for a team by himself

FreeType

Two security issues have been identified in FreeType's CFF driver:

CVE-2014-2240 (out-of-bounds stack read/write)
CVE-2014-2241 (denial of service via triggerable assertion)

Solution: Upgrade to FreeType 2.5.3.

In order to compile FreeType 2.5.3 Harfbuzz needs to be updated as well.

Mats

Update 20140316

1. 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)
• Upgrade to HarfBuzz 0.9.26 [OPTIONAL STEP]
• Rebuild FreeType 2.5.3 (2nd pass with HarfBuzz support) [OPTIONAL STEP]
  
  Keep in mind lots of things depend on HarfBuzz and FreeType so upgrading these two libs is done at your own risk.

https://www.mozilla.org/security/kno...irefoxESR.html

Firefox ESR 24.4.0 fixes some critical vulnerabilities. I'm trying to debug a failed build as I write.