-   Slackware (
-   -   [Slackware security] vulnerabilities outstanding 20140101 (

mancha 04-24-2015 12:33 AM

Update 20150424
  1. wpa_supplicant

    A vulnerability related to SSID processing in wpa_supplicant's Wi-Fi P2P implementation can be exploited by remote attackers within
    radio distance to cause denials of service, information disclosure, and potentially arbitrary code execution. (CVE-2015-1863)

    Vulnerable code was introduced in wpa_supplicant 1.0 and affects Slackware 14.1 through current (note: though Slackware 14.0
    ships wpa_supplicant 1.0, it doesn't build it with Wi-Fi peer-to-peer support so is not vulnerable).

    Recommendation for Slackware 14.1 & current: Rebuild wpa_supplicant after applying upstream's fix.

mancha 04-27-2015 02:34 PM

Update 20150427
  1. tcpdump

    Several overflow and OOB issues were fixed in tcpdump 4.7.0, 4.7.2, and 4.7.4. The security impact of these ranges from DoS to
    possible arbitrary code execution. (CVE-2014-9140; CVE-2015-0261; CVE-2015-2153; CVE-2015-2154; and CVE-2015-2155)

    The last time tcpdump issues were reported on this thread, I developed backported fixes for use on Slackware. This time around,
    I recommend interested slackers upgrade their versions.

    Recommendation: Upgrade to tcpdump 4.7.4 (sig)

Speek 04-28-2015 03:50 AM


From: Arch Linux alert ASA-201504-25 (glibc) (The last link in that article contains the patch)


A buffer overflow in gethostbyname_r() and related functions performing
DNS requests has been fixed. If the NSS functions were called with a
misaligned buffer, the buffer length change due to pointer alignment was
not taken into account. This could result in application crashes or
potentially arbitrary code execution using crafted but syntactically
valid DNS responses.

A remote attacker can crash or execute arbitrary code by crafting
malicious DNS responses to the requests made by an application. To be
vulnerable, the application must be passing a misaligned buffer to
gethostbyname_r() or related functions.

mancha 05-01-2015 12:15 PM

Update 20150501
  1. curl

    This is an update to my recent curl report in post #360. It was determined many users of curl (applications linking libcurl and cli
    end-users) were not aware that, when using a proxy server, curl by default sends custom HTTP headers to both the proxy and
    the destination. This default is problematic when sensitive headers sent via SSL/TLS to the destination are seen elsewhere.

    Recommendation: Upgrade to curl 7.42.1 (sig)

mancha 05-05-2015 03:41 PM

Update 20150505
  1. MariaDB

    To update pataphysician's post #358, the following were fixed in MariaDB 5.5.42:

    • CVE-2015-2568
    • CVE-2015-2573
    • CVE-2015-0433
    • CVE-2015-0441

    And, these fixed in MariaDB 5.5.43:

    • CVE-2015-0501
    • CVE-2015-2571
    • CVE-2015-0505
    • CVE-2015-0499

    Recommendation for Slackware 14.1: Upgrade to MariaDB 5.5.43 (sig)

    Note: Slackware 14.0 ships MySQL 5.5.36 which has known vulnerabilities. Users on that system should upgrade to MySQL 5.5.43
    or transition to MariaDB 5.5.43. The versions of MySQL shipped with Slackware 13.0-13.37 have EOL'd so users on those systems
    should take appropriate action.

mancha 05-06-2015 11:57 AM

  1. libssh

    A vulnerability in the handling of SSH_MSG_NEWKEYS and SSH_MSG_KEXDH_REPLY messages allows an attacker to DoS
    attack clients and servers. (CVE-2015-3146)

    Recommendation: upgrade to libssh 0.6.5 (sig)

mancha 05-07-2015 02:39 PM

  1. Dnsmasq

    A vulnerability was discovered in Dnsmasq that can be exploited via crafted DNS requests to expose potentially sensitive information.

    Recommendation (current): Rebuild Dnsmasq 2.72 after applying dnsmasq-2.72_CVE-2015-3294.diff.

    Note: Patch applies with harmless offsets to Dnsmasq 2.57 so can be used on Slackware 13.37-14.1 as well.

mats_b_tegner 05-12-2015 07:04 AM

Security updates for mariadb, mysql and wpa-supplicant are available according to the ChangeLogs and slackware-security mailing list.

Didier Spaier 05-14-2015 03:02 AM

Virtualized Environment Neglected Operations Manipulation
In QEMU's floppy disk controller: During processing of certain commands such as FD_CMD_READ_ID and D_CMD_DRIVE_SPECIFICATION_COMMAND the fifo memory access could get out of bounds leading to memory corruption with values coming from the guest, possibly giving access to sensitive data. Ref.: VENOM vulnerabilty.

There is a patch for QEMU CVE-2015-3456 but other products that use the same code are affected, see the above referenced document.

I post this because, although QEMU be not shipped in Slackware, many Slackers use the SlackBuild available @

PS I see that a patched version has been released on Sun May 17 16:48:27 UTC 2015, thanks Willy.

willysr 05-14-2015 01:05 PM

Already patched on my branch, will be part of this week's update

MadMaverick9 05-16-2015 12:05 AM

Firefox downloads binary blob "" (by Cisco Systems Inc.) without user consent
Firefox downloads a binary blob called "" created by Cisco Systems Inc. without asking the user for consent. It seems this is used by webrtc. As far as I can tell this started with Firefox 33.

debian bug 769716
mozilla bug 1100304

You can see this plugin in "about:plugins".

The only post that I found on LQ related to this is by Jeremy made in 2013:

I added the following lines to "prefs.js" to make sure Firefox does not do this anymore:

user_pref("media.gmp-gmpopenh264.autoupdate", false);
user_pref("media.gmp-gmpopenh264.enabled", false);
user_pref("media.gmp-gmpopenh264.provider.enabled", false);
user_pref("media.gmp-manager.url", "http://localhost/mozilla/update.xml");

And of course delete any "libgmp*" files in my profile.

cwizardone 05-16-2015 01:01 AM

Would you be kind enough to elaborate as to why this is a security risk?

bassmadrigal 05-16-2015 06:33 PM

This is an opensource codec from Cisco for h264 videos. The only reason it isn't included already in Firefox is because Mozilla's license doesn't allow it to be distributed, so a binary is downloaded when the browser opens.

However, Mozilla is the one compiling the binary (and generating a cryptographic hash) not Cisco, and then Cisco grabs the binary from Mozilla to host/distribute. Once the binary is downloaded into Firefox, it is verified that the cryptographic hash matches to make sure no tampering has occurred.

And the source to said binary is on github

j_v 05-17-2015 07:57 AM

@bassmadrigal Thanks for the clarification. I had done some searching and perusal of some of the reports related to the Cisco h264 topic at mozilla, fedora/redhat, and debian; but had not yet come across this information. Much appreciated.

cwizardone 05-17-2015 09:26 AM


Many Thanks for the information!

All times are GMT -5. The time now is 07:37 PM.