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

2 members found this post helpful.

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)

--mancha

3 members found this post helpful.

glibc-2.21

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

CVE-2015-1781

Description
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.

Impact
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.

2 members found this post helpful.

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.
   (CVE-2015-3153)
   
   Recommendation: Upgrade to curl 7.42.1 (sig)

2 members found this post helpful.

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

20150506

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

20150507

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.

--mancha

1 members found this post helpful.

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

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 @ SlackBuilds.org.

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

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

1 members found this post helpful.

Firefox downloads a binary blob called "libgmpopenh264.so" 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:
http://www.linuxquestions.org/questi...5B-4175482797/

I added the following lines to "prefs.js" to make sure Firefox does not do this anymore:
And of course delete any "libgmp*" files in my profile.

@MadMaverick9,
Would you be kind enough to elaborate as to why this is a security risk?
Thanks.

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

5 members found this post helpful.

@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.

@bassmadrigal,

Many Thanks for the information!