LinuxQuestions.org - [Slackware security] vulnerabilities outstanding 20140101

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - [Slackware security] vulnerabilities outstanding 20140101 (https://www.linuxquestions.org/questions/slackware-14/%5Bslackware-security%5D-vulnerabilities-outstanding-20140101-a-4175489800/)

Quote:

Originally Posted by volkerdi (Post 5540208)

And here's the complete information. We quietly updated ImageMagick in -current, but it seems the fixes are incomplete.

http://seclists.org/oss-sec/2016/q2/205

I'm not sure what can be done in 14.0 and 14.1 without isolating and backporting the fixes, since the shared library versions have been bumped since then and we can't recompile everything as part of a fix. But pretty much anyone using ImageMagick to process untrusted files should apply the mitigations from the link above.

ImageMagick 6.9.3-10 is available now:
https://www.imagemagick.org/discours...hp?f=4&t=29588

https://www.imagemagick.org/download....9.3-10.tar.xz
https://www.imagemagick.org/download...-10.tar.xz.asc

ImageMagick-7.0.1-1, has been released.

Source code is available,

ftp://ftp.imagemagick.org/pub/ImageM...7.0.1-1.tar.xz

or

https://www.imagemagick.org/script/binary-releases.php

More on the ImageMagick security problems:

http://arstechnica.com/security/2016...rocessing-bug/

Quote:

Attackers have wasted no time targeting a critical vulnerability that could allow them to take complete control over websites running a widely used image-processing application, security researchers said.

As Ars reported last week, a vulnerability in ImageMagick allows hackers to execute code of their choice on webservers that use the app to resize or crop user-uploaded images. Over the past few days, security researchers said, attackers have begun uploading booby-trapped images in an attempt to exploit the vulnerability, which is indexed as CVE-2016-3714. CloudFlare, a content delivery network that helps secure and optimize websites, has updated its Web application firewall to block exploits in an attempt to protect customers who have yet to patch the remote code-execution threat.

"We began watching the exploitation of CVE-2016-3714 as soon as the WAF rule went live across our network," CloudFlare researcher John Graham-Cumming wrote in a blog post published Monday. "The bad news is that this vulnerability is being actively used by hackers to attack websites."

The most dangerous exploit he discussed is one that's disguised as a JPG image. In reality, it's not an image file at all and is instead malware designed to upload a malicious python file. Once the file is in place, the vulnerable Web server executes it, allowing the attacker to open a command shell. From then on, the attacker has the same control over the server that a normal administrator would have. A variant of this attack eliminates the need to download the python program and includes it in the payload itself.

"All these payloads are designed to give the hacker unfettered access to the vulnerable Web server," Graham-Cumming wrote. "With a single exploit they can get remote access and then proceed to further hack the vulnerable Web server at their leisure."

Researchers at website security firm Sucuri have also witnessed attackers attempting to install reverse shells on vulnerable servers. One of the exploits was beaconing back to an IP address registered to Linode, a virtual private server provider the attackers were likely using to host a command and control channel. The actual HTTP requests used in the attack came from a server with a Taiwanese IP address.

The vulnerability involves the way ImageMagick parses video files with the MVG extension. Attackers can disguise them as JPG files that contain malformed file paths that allow remote attackers to break out of the image manipulation flow and execute their own shell commands. Security researcher Ryan Huber has a more technically detailed explanation of the vulnerability here.

Both CloudFlare and Sucuri make mention of a patch, but so far there is no explicit notification of one on the ImageMagick website. Servers that use the app directly or indirectly should at a minimum update their site configurations to implement these policies.

^^ :thumbsup:
Fixed in Tuesday night's change log.
Many Thanks.
:hattip:

Quote:

Originally Posted by volkerdi (Post 5540208)

... 14.0 and 14.1 ... should apply the mitigations from the link above.

Thank you for pushing the fix Pat. It would be helpful if the package handled the ImageMagick configuration files using the 'new' extension, so that the upgrade hadn't silently clobbered my settings.

Quote:

Originally Posted by Xsane (Post 5545588)

Thank you for pushing the fix Pat. It would be helpful if the package handled the ImageMagick configuration files using the 'new' extension, so that the upgrade hadn't silently clobbered my settings.

In -current, .new is used now. But for the stable patches, your settings would have been clobbered even if the install script had been changed to use .new, so there wasn't going to be any immediate benefit to changing the config file handling in those.

It seems, another critical problem with Imagemagick (CVE-2016-5118):
http://www.openwall.com/lists/oss-security/2016/05/29/7

ntp 4.2.8p8 addresses the following:
http://support.ntp.org/bin/view/Main...ulnerabilities

Quote:

Fri Jun 3 23:36:07 UTC 2016
n/ntp-4.2.8p8-x86_64-1.txz: Upgraded.

libjpeg-turbo 1.5.0 released 2016-06-07
sourceforge link

Maybe not so relevant to the main tree, but alien package for 14.1 is 1.2.0 and #gentoo warned about this.
Builds fine with the old SlackBuild, just needs a version bump.

Quote:

Originally Posted by elcore (Post 5557945)

libjpeg-turbo 1.5.0 released 2016-06-07
sourceforge link.....

Good to know.
The version in -current is, libjpeg-turbo-1.4.2.
:hattip:

Update 20160621

OpenSSL

CVE-2016-2177

OpenSSL through 1.0.2h incorrectly uses pointer arithmetic for heap-buffer boundary checks, which might allow remote attackers to cause a denial of service (integer overflow and application crash) or possibly have unspecified other impact by leveraging unexpected malloc behavior

Solution for 14.1: Apply openssl-1.0.1_CVE-2016-2177.diff and rebuild
CVE-2016-2178

The dsa_sign_setup function in OpenSSL through 1.0.2h does not properly ensure the use of constant-time operations, which makes it easier to discover DSA private keys via a timing side-channel attacks.

Solution for 14.1: Apply openssl-1.0.1_CVE-2016-2178.diff and rebuild

--mancha

PS If you run self-tests at compile time (i.e. make test), you need to update expired SMIME certs bundled in 1.0.1t for use in the CMS tests. Apply openssl-1.0.1t_smime-certs.diff and build.

Quote:

Originally Posted by mancha (Post 5564063)

OpenSSL[*]CVE-2016-2177[*]CVE-2016-2178

These are both rated as LOW severity by upstream, which is why you're not seeing a new upstream release right now. In addition, Solar Designer has expressed concern that the first patch may be incorrect, and more people need to take a look at it before it goes into the next OpenSSL release.

I'm going to pass on these, and don't think anyone needs to be terribly concerned.

Quote:

Originally Posted by volkerdi (Post 5564301)

These are both rated as LOW severity by upstream, which is why you're not seeing a new upstream release right now.

The roll-out suggests triaging resulted in preliminary ratings of low. After limited review I agree these appear to be low-to-medium severity with 2177 a bit more concerning than 2178.

Re: CVE-2016-2177, I waited before posting upstream's fix given concerns raised the fix might be incomplete. Two weeks since the public commit, OpenSSL's fix still stands.

Re: CVE-2016-2178, successful exploitation appears complex (as is the case with most side-channel timing attacks). Nevertheless, the fix is straightforward and good to have.

I've not personally had time to audit the affected code but have deployed both fixes on my systems.

--mancha

Thunderbird 45.2.0

samba-4.4.5 is released and fix one security issue.

Quote:

CVE-2016-2119:
It's possible for an attacker to downgrade the required signing for
an SMB2/3 client connection, by injecting the SMB2_SESSION_FLAG_IS_GUEST
or SMB2_SESSION_FLAG_IS_NULL flags.

This means that the attacker can impersonate a server being connected to by
Samba, and return malicious results.

The primary concern is with winbindd, as it uses DCERPC over SMB2 when talking
to domain controllers as a member server, and trusted domains as a domain
controller. These DCE/RPC connections were intended to protected by the
combination of "client ipc signing" and
"client ipc max protocol" in their effective default settings
("mandatory" and "SMB3_11").

Additionally, management tools like net, samba-tool and rpcclient use DCERPC
over SMB2/3 connections.

By default, other tools in Samba are unprotected, but rarely they are
configured to use smb signing, via the "client signing" parameter (the default
is "if_required"). Even more rarely the "client max protocol" is set to SMB2,
rather than the NT1 default.

If both these conditions are met, then this issue would also apply to these
other tools, including command line tools like smbcacls, smbcquota, smbclient,
smbget and applications using libsmbclient.

https://download.samba.org/pub/samba...a-4.4.5.tar.gz
https://download.samba.org/pub/samba...-4.4.5.tar.asc