[Slackware security] vulnerabilities outstanding 20140101

mralk3 · 05-20-2015, 03:06 PM

CVE-2015-3306

Original release date: 05/18/2015

Quote:

The mod_copy module in ProFTPD 1.3.5 allows remote attackers to read and write to arbitrary files via the site cpfr and site cpto commands.

Slackware64 14.1 is running proftpd version:

Code:

proftpd-1.3.4e-x86_64-1_slack14.1

I am not sure how to go about auditing for this vulnerability to be sure its actually a problem. Maybe it isn't considered a big issue, but all the same I thought I would notify.

mralk3 · 05-20-2015, 11:00 PM

Quote:

Originally Posted by mralk3

CVE-2015-3306

Original release date: 05/18/2015

Slackware64 14.1 is running proftpd version:

Code:

proftpd-1.3.4e-x86_64-1_slack14.1

I am not sure how to go about auditing for this vulnerability to be sure its actually a problem. Maybe it isn't considered a big issue, but all the same I thought I would notify.

ProFTPD 1.3.5 mod_copy Exploitdb

BrZ · 05-21-2015, 10:17 AM

CVE-2015-0797
GStreamer before 1.4.5, as used in Mozilla Firefox before 38.0, Firefox ESR 31.x before 31.7, and Thunderbird before 31.7 on Linux, allows remote attackers to cause a denial of service (buffer over-read and application crash) or possibly execute arbitrary code via crafted H.264 video data in an m4v file.

Mozilla Foundation Security Advisory 2015-47
Buffer overflow parsing H.264 video with Linux Gstreamer

Fix?

Quote:

Description: Fix buffer overflow in mp4 parsing
Author: Ralph Giles <giles@mozilla.com>

--- gst-plugins-bad0.10-0.10.23.orig/gst/videoparsers/gsth264parse.c
+++ gst-plugins-bad0.10-0.10.23/gst/videoparsers/gsth264parse.c
@@ -384,6 +384,11 @@ gst_h264_parse_wrap_nal (GstH264Parse *

GST_DEBUG_OBJECT (h264parse, "nal length %d", size);

+ if (size > G_MAXUINT32 - nl) {
+ GST_ELEMENT_ERROR (h264parse, STREAM, FAILED, (NULL),
+ ("overflow in nal size"));
+ return NULL;
+ }
buf = gst_buffer_new_and_alloc (size + nl + 4);
if (format == GST_H264_PARSE_FORMAT_AVC) {
GST_WRITE_UINT32_BE (GST_BUFFER_DATA (buf), size << (32 - 8 * nl));
@@ -452,6 +457,11 @@ gst_h264_parse_process_nal (GstH264Parse
GST_DEBUG_OBJECT (h264parse, "not processing nal size %u", nalu->size);
return;
}
+ if (G_UNLIKELY (nalu->size > 20 * 1024 * 1024)) {
+ GST_DEBUG_OBJECT (h264parse, "not processing nal size %u (too big)",
+ nalu->size);
+ return;
+ }

/* we have a peek as well */
nal_type = nalu->type;

mats_b_tegner · 05-22-2015, 01:02 PM

Quote:

Originally Posted by BrZ

CVE-2015-0797
GStreamer before 1.4.5, as used in Mozilla Firefox before 38.0, Firefox ESR 31.x before 31.7, and Thunderbird before 31.7 on Linux, allows remote attackers to cause a denial of service (buffer over-read and application crash) or possibly execute arbitrary code via crafted H.264 video data in an m4v file.

Mozilla Foundation Security Advisory 2015-47
Buffer overflow parsing H.264 video with Linux Gstreamer

Fix?

I just compiled GStreamer, gst-plugins-base and gst-plugins-good versions 1.4.5 under -current. I wonder if you need to recompile Firefox and Thunderbird against the new libraries as well?

Mats

BrZ · 05-22-2015, 02:10 PM

Debian is marking 'gst-plugins-bad0.10', 'icedove' and 'iceweasel' as vulnerable, but wait a bit for the fix to 'logjam' as FF take some time and lots of resource to build...

mats_b_tegner · 05-22-2015, 03:34 PM

Okay, I guess I'll wait until there is a patch against Logjam for Firefox.

mancha · 05-27-2015, 02:28 AM

Hi.

Here's a bit more info on the topics of the last few posts...

proftpd

Quote:

Originally Posted by mralk3

CVE-2015-3306
Original release date: 05/18/2015

Slackware64 14.1 is running proftpd version: proftpd-1.3.4e-x86_64-1_slack14.1

I am not sure how to go about auditing for this vulnerability to be sure its actually a problem. Maybe it isn't considered a big issue, but all the same I thought I would notify.

Slackware doesn't build proftpd with mod_copy so the version it ships isn't vulnerable to CVE-2015-3306. It seems Slackware
current patched its proftpd anyways though given the build configuration it wasn't necessary.

Recommendation: Nothing needed unless you've built a customized copy of proftpd with mod_copy support.

Firefox+GStreamer

Quote:

Originally Posted by BrZ

CVE-2015-0797
GStreamer before 1.4.5, as used in Mozilla Firefox before 38.0, Firefox ESR 31.x before 31.7, and Thunderbird before 31.7 on Linux, allows remote attackers to cause a denial of service (buffer over-read and application crash) or possibly execute arbitrary code via crafted H.264 video data in an m4v file.

Mozilla Foundation Security Advisory 2015-47
Buffer overflow parsing H.264 video with Linux Gstreamer

Fix?

Quote:

Originally Posted by mats_b_tegner

I just compiled GStreamer, gst-plugins-base and gst-plugins-good versions 1.4.5 under -current. I wonder if you need to recompile Firefox and Thunderbird against the new libraries as well?

Mats

This bug is a bit confusing in terms of which versions are affected. The bottom line is the bug is in h264parse from gst-plugins-bad
(which Slackware doesn't ship). However, it's available from SBo and if you install it, Slackware's FF will automatically detect it and
use it if necessary.

Recommendation: Mozilla has patched their products (FF 38, FF ESR 31.8, and Thunderbird 31.7) so they now blacklist h264parse.
Make sure you have at least these versions (for this issue and others). Also, if you've installed gst-plugins-bad apply Debian's patch
(posted by BrZ in post #378) because other applications that use h264parse are potentially vulnerable as well.

Note1: If you want to use GStreamer 1.x+ with FF you'll have to re-compile FF with --enable-gstreamer=1.0 or so. You might have
valid reasons to want to transition Firefox to the new GStreamer API but keep in mind upgrading won't affect how FF deals with
CVE-2015-0797 because at least for the time being, Mozilla's blacklisting of h264parse isn't version dependent.

Note2: I don't believe GStreamer 1.x has fixed this bug yet (contrary to security reports).

Firefox+Logjam

Quote:

Originally Posted by mats_b_tegner

Okay, I guess I'll wait until there is a patch against Logjam for Firefox.

Mozilla will be releasing a new NSS library that rejects FF DH groups smaller than 1024 bits. Currently the minimum is 512 bits (actually
because of a bug in length calculations the minimum is effectively 505 bits) which means it'll accept Logjammable DHE groups. The
fix is planned for inclusion in FF 39 (and the next ESRs).

Recommendation: Until FF releases new versions with the new NSS bundled in, you can avoid Logjam by disabling all DHE cipher
suites. Search for them by putting security.ssl3.dhe in the about:config search bar (see attached pic). Your FF might be newer
and have less than the nine ciphers shown in the pic; just set whichever ones you do have to false.

--mancha

mralk3 · 05-27-2015, 12:55 PM

Quote:

Originally Posted by mancha

Slackware doesn't build proftpd with mod_copy so the version it ships isn't vulnerable to CVE-2015-3306. It seems Slackware current patched its proftpd anyways though given the build configuration it wasn't necessary.

Recommendation: Nothing needed unless you've built a customized copy of proftpd with mod_copy support.

I will check the source directory of my mirror first for build criteria for now on to see how packages are built. Thanks for the insight.

mancha · 06-11-2015, 11:40 AM

Update 20150611

OpenSSL

OpenSSL today released a security advisory with details on 5 new vulnerabilities (4 moderate, 1 low) and a Logjam hardening measure.

R̶e̶c̶o̶m̶m̶e̶n̶d̶a̶t̶i̶o̶n̶:̶ ̶U̶p̶g̶r̶a̶d̶e̶ ̶t̶o̶ ̶O̶p̶e̶n̶S̶S̶L̶ ̶1̶.̶0̶.̶1̶n̶ ̶(s̶i̶g̶) ̶a̶n̶d̶/̶o̶r̶ ̶O̶p̶e̶n̶S̶S̶L̶ ̶0̶.̶9̶.̶8̶z̶g̶ ̶(̶s̶i̶g̶)̶,̶ ̶a̶s̶ ̶a̶p̶p̶l̶i̶c̶a̶b̶l̶e̶.̶

New Recommendation: I've been made aware there might be ABI breakage from OpenSSL 1.0.1m -> OpenSSL 1.0.1n. Postponing
upgrades until that is sorted out is probably prudent.
libwmf

ReadBMPImage in libwmf is vulnerable to an overflow that can be exploited using crafted input to cause a DoS or potentially execute
arbitrary code. (CVE-2015-0848)

To test:
Code:
```
$ wmf2svg --wmf-fontdir=/tmp/seggyfault bmpoverflow.wmf
```
Recommendation: Apply libwmf-0.2.8.4_CVE-2015-0848.diff and rebuild.
Ruby

Ruby’s OpenSSL extension suffers a vulnerability through overly permissive matching of hostnames. (CVE-2015-1855)

Recommendation: 14.1 users apply ruby-1.9.3-p484_CVE-2015-1855.diff; current users apply ruby-1.9.3-p551_CVE-2015-1855.diff.

--mancha

"Fama refert nostros te, Fidentine, libellos non aliter populo quam recitare tuos."

--Martial, Epigrammata

mancha · 06-12-2015, 10:56 AM

Update 20150612

OpenSSL

OpenSSL released new versions (1.0.1o & 1.0.2c) to address the HMAC_CTX ABI breakage I allude to in the previous post.

Recommendation: Upgrade to OpenSSL 1.0.1o (sig) and/or OpenSSL 0.9.8zg (sig), as applicable.

--mancha

mats_b_tegner · 06-12-2015, 04:58 PM

Quote:

Originally Posted by mancha

Update 20150612

OpenSSL

OpenSSL released new versions (1.0.1o & 1.0.2c) to address the HMAC_CTX ABI breakage I allude to in the previous post.

Recommendation: Upgrade to OpenSSL 1.0.1o (sig) and/or OpenSSL 0.9.8zg (sig), as applicable.

--mancha

Fixed according to the latest ChangeLog for -current:
"Fri Jun 12 17:58:45 UTC 2015
a/openssl-solibs-1.0.1o-x86_64-1.txz: Upgraded.
n/openssl-1.0.1o-x86_64-1.txz: Upgraded.
New release to resolve 1.0.1n HMAC ABI incompatibility."

mancha · 06-25-2015, 01:04 PM

Update 20150625

Python(*)

Python 2.7.5, as shipped by Slackware 14.1, is vulnerable to potential exploitation of numerous security issues (e.g. see posts #78
and #249).

In addition, Python 2.7.9 fixes DoS issues in smptlib and poplib and XMLRPC (CVE-2013-1752, CVE-2013-1753) and introduces
hardening features (i.e. disabling SSLv3 in httplib and enabling HTTPS certificate validation by default). Python 2.7.10 fixes a potential
buffer overflow in PyUnicode_FromFormatV.

Recommendation: Slackware 14.1 & current users should upgrade to Python 2.7.10.

--mancha

(*)Though non-venomous, it's capable of deadly constriction

1337_powerslacker · 06-26-2015, 10:28 AM

Attempts to build the latest Python, 2.7.10, using the -current SlackBuild, results in the following error:

Code:

Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff -uar Python-2.7.2.orig/setup.py Python-2.7.2/setup.py
|--- Python-2.7.2.orig/setup.py 2011-06-11 18:46:28.000000000 +0300
|+++ Python-2.7.2/setup.py      2011-06-13 12:29:32.241106466 +0300
--------------------------
patching file setup.py
Using Plan A...
Hunk #1 FAILED at 369.
Hunk #2 succeeded at 762 (offset 85 lines).
Hunk #3 succeeded at 801 (offset 86 lines).
1 out of 3 hunks FAILED -- saving rejects to file setup.py.rej
done

When I disabled the x86_64 patch, the package built without errors; however, the stated purpose is to place the files in /usr/lib64 instead of /usr/lib, and so this solution, at least to me, is unacceptable. Is there anyone who can provide an updated version of python.x86_64.diff.gz to successfully patch against 2.7.10? Thanks.

mancha · 06-26-2015, 11:08 AM

Quote:

Originally Posted by mattallmill

Is there anyone who can provide an updated version of python.x86_64.diff.gz to successfully patch against 2.7.10? Thanks.

Hi.

You should be able to use python.x86_64.diff.gz from Slackware-current used to patch 2.7.9. Let me know if that also gives you problems.

--mancha

1337_powerslacker · 06-26-2015, 01:07 PM

Quote:

Originally Posted by mancha

Hi.

You should be able to use python.x86_64.diff.gz from Slackware-current used to patch 2.7.9. Let me know if that also gives you problems.

--mancha

Thanks mancha. For some reason, I thought I had the updated patches. I used a script to download all of -current, and I thought, from the date of the updated file, that I had downloaded it after the date. Apparently, I had not. Thanks for the file. It's compiling now.