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/)

Apparently, OpenBSD has got rid of Intel HyperThreading due to Spectre. (It's no problem to get rid of it on amd64, I've had this disabled in my kernels for couple of years now)

Quote:

Originally Posted by elcore (Post 5869606)

Apparently, OpenBSD has got rid of Intel HyperThreading due to Spectre. (It's no problem to get rid of it on amd64, I've had this disabled in my kernels for couple of years now)

It looks like a new type of cache timing attack dubbed TLBleed:
https://www.theregister.co.uk/2018/0...yperthreading/
https://www.theregister.co.uk/2018/0...key_data_leak/
The details will be revealed in a few days at the BlackHat 2018 conference:
https://www.blackhat.com/us-18/brief...t-enough-10149

bind-9.10.8 is released with security fixes.

Quote:

Security Fixes

When recursion is enabled but the allow-recursion and allow-query-cache ACLs are not specified, they should be limited to local networks, but they were inadvertently set to match the default allow-query, thus allowing remote queries. This flaw is disclosed in CVE-2018-5738. [GL #309]

curl-7.61.0 is released with one security fix:

Quote:

SMTP send heap buffer overflow
==============================

Project curl Security Advisory, July 11th 2018 -
[Permalink](https://curl.haxx.se/docs/adv_2018-70a2.html)

VULNERABILITY
-------------

curl might overflow a heap based memory buffer when sending data over SMTP and
using a reduced read buffer.

When sending data over SMTP, curl allocates a separate "scratch area" on the
heap to be able to escape the uploaded data properly if the uploaded data
contains data that requires it.

The size of this temporary scratch area was mistakenly made to be `2 *
sizeof(download_buffer)` when it should have been made `2 *
sizeof(upload_buffer)`.

The upload and the download buffer sizes are identically sized by default
(16KB) but since version 7.54.1, curl can resize the download buffer into a
smaller buffer (as well as larger). If the download buffer size is set to a
value smaller than 10923, the `Curl_smtp_escape_eob()` function might overflow
the scratch buffer when sending contents of sufficient size and contents.

The curl command line tool lowers the buffer size when `--limit-rate` is set
to a value smaller than 16KB.

We are not aware of any exploit of this flaw.

TEST CASES
----------
Here's a shell script

# Setup an SMTP end-point, make file, run curl
$ printf '220 Hi\n250 SIZE 10000\n250 OK\n250 OK\n354 send data\n' | nc -l -p 2525 >/dev/null &
$ printf '%5000s' > mail.txt
$ curl -v smtp://localhost:2525 --mail-from me --mail-rcpt root@localhost --upload-file mail.txt --limit-rate 1024

PHP code:

<?php
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "smtp://localhost:2525");
curl_setopt($ch, CURLOPT_BUFFERSIZE, 1024);
curl_setopt($ch, CURLOPT_UPLOAD, 1);
curl_setopt($ch, CURLOPT_MAIL_FROM, "me");
curl_setopt($ch, CURLOPT_MAIL_RCPT, ["root@localhost"]);
curl_setopt($ch, CURLOPT_VERBOSE, 1);
$eof = false;
curl_setopt($ch, CURLOPT_READFUNCTION, function($ch, $stream, $maxSize) {
global $eof;
echo "Max Size: [$maxSize]\n";
if ($eof) {
return "";
}
$eof = true;
return str_repeat(" ", $maxSize);
});
curl_exec($ch);
curl_close($ch);

INFO
----

This bug was introduced in April 2017 in [this
commit](https://github.com/curl/curl/commit/e40e9d7f0decc79) when we
introduced support for buffer resize. The scratch buffer was mistakenly made
to use the dynamic size when it should kept using the fixed upload buffer
size.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name
CVE-2018-0500 to this issue.

CWE-122: Heap-based Buffer Overflow

AFFECTED VERSIONS
-----------------

- Affected versions: curl 7.54.1 to and including curl 7.60.0
- Not affected versions: curl < 7.54.1 and curl >= 7.61.0

libcurl is used by many applications, but not always advertised as such.

THE SOLUTION
------------

In curl version 7.61.0, curl will use the upload buffer size as base for the
scratch area allocation.

A [patch for CVE-2018-0500](https://github.com/curl/curl/commit/ba1dbd78e5f1e.patch) is
available.

RECOMMENDATIONS
---------------

We suggest you take one of the following actions immediately, in order of
preference:

A - Upgrade curl to version 7.61.0

B - Apply the patch to your version and rebuild

C - Avoid using SMTP uploads with CURLOPT_BUFFERSIZE set below 10923

New Spectre Variant dubbed Bounds Check Bypass Store - CVE-2018-3693
https://cve.mitre.org/cgi-bin/cvenam...=CVE-2018-3693
Intel's Security Advisory:
https://01.org/security/advisories/intel-oss-10002
Research Paper:
https://people.csail.mit.edu/vlk/spectre11.pdf
It looks to be a sub-variant of: CVE-2017-5753 aka Spectre Variant 1
Not yet listed in the capabilities of the spectre-meltdown-checker:
https://github.com/speed47/spectre-meltdown-checker

Intel's latest white paper release suggest SW mitigation (kernel):
https://software.intel.com/sites/def...hite-Paper.pdf

mutt 1.10.1 released

With important security fixes. Quoting the message from Kevin J. McCarthy on the mutt-announce mailing list:

Quote:

This is a bug fix release, and includes a few important security fixes. I strongly recommend IMAP and POP users upgrade as soon as possible.

Thanks to Jude DaShiell for the heads up.

Details about a new Spectre variant has just been released, it's called SpectreRSB and targets the CPU Return Stack Buffer (RSB), has no CVE assigned yet and Intel states that it's related to Spectre variant 2 - CVE-2017-5715
https://www.bleepingcomputer.com/new...ed-spectrersb/
"Researchers said they reported the issue to Intel, but also to AMD and ARM. Researchers say they only tested SpectreRSB on Intel CPUs, but because AMD and ARM processors also use RSBs to predict return addresses, they are, most likely, affected as well. Red Hat is also investigating the issue."
https://www.theregister.co.uk/2018/0..._stack_buffer/

mariadb-10.0.36 is released with many security fixes.
https://mariadb.com/kb/en/mdb-10036-rn/

Linux kernel (versions 4.9+) is vulnerable to DoS attacks through specially modified TCP packets.
CVE-2018-5390
Linux kernel versions 4.9+ can be forced to make very expensive calls to tcp_collapse_ofo_queue() and tcp_prune_ofo_queue() for every incoming packet which can lead to a denial of service.
https://cve.mitre.org/cgi-bin/cvenam...=CVE-2018-5390

Kernel patch:
https://git.kernel.org/pub/scm/linux...689a478f82e72e

Some details from Akamai:
https://blogs.akamai.com/2018/08/lin...erability.html
& from CERT:
https://www.kb.cert.org/vuls/id/962459

Quote:

Originally Posted by abga (Post 5888830)

this is actually patched already in Slackware current (the only one to which this applies) since the update to kernel 4.14.59.

Quote:

Originally Posted by ponce (Post 5888833)

this is actually patched already in Slackware current (the only one to which this applies) since the update to kernel 4.14.59.

Thanks for the confirmation, haven't checked myself the source code upon which the -current kernel was build but noticed that it was upgraded 4(5) times ever since the kernel patch mitigating CVE-2018-5390 was introduced (23 Jul 2018). However, there's no mention of CVE-2018-5390 in:
ftp://ftp.osuosl.org/pub/slackware/s.../ChangeLog.txt

Quote:

Originally Posted by abga (Post 5888840)

Thanks for the confirmation, haven't checked myself the source code upon which the -current kernel was build but noticed that it was upgraded 3(4) times ever since the kernel patch mitigating CVE-2018-5390 was introduced (27 Jul 2018). However, there's no mention of CVE-2018-5390 in:
ftp://ftp.osuosl.org/pub/slackware/s.../ChangeLog.txt

...but you can find the interested commit in 4.14.59's ChangeLog.

Quote:

Originally Posted by ponce (Post 5888850)

...but you can find the interested commit in 4.14.59's ChangeLog.

... but I thought you have checked the /net/ipv4/tcp_input.c from the kernel source that Patrick used&published. But then I believe that Patrick took the kernel source and did not modify it at all, which is one of the qualities of Slackware.
On security patches you don't really need to check the kernel changelog for a specific version because they are applied to all vulnerable branches (backported too). ;)
I believe the value of my original post and this discussion is to make Slackers running -current aware that they should upgrade their kernel to the latest available on Slackware mirrors ASAP.

bind-9.10.8-P1, 9.12.2-P1 are released with security fix.

Quote:

A rarely-used feature in BIND has a flaw which can cause named to
exit with an INSIST assertion failure.

CVE: CVE-2018-5740
Document Version: 2.0
Posting date: 08 August 2018
Program Impacted: BIND
Versions affected: 9.7.0->9.8.8, 9.9.0->9.9.13, 9.10.0->9.10.8,
9.11.0->9.11.4, 9.12.0->9.12.2, 9.13.0->9.13.2
and also versions of BIND 9 Supported Preview Edition
Severity: High (but only for servers on which the
"deny-answer-aliases"
feature is explicitly enabled)
Exploitable: Remotely

Description:

"deny-answer-aliases" is a little-used feature intended to help
recursive server operators protect end users against DNS rebinding
attacks, a potential method of circumventing the security model
used by client browsers. However, a defect in this feature makes
it easy, when the feature is in use, to experience an INSIST
assertion failure in name.c.

Impact:

Accidental or deliberate triggering of this defect will cause
an INSIST assertion failure in named, causing the named process
to stop execution and resulting in denial of service to clients.
Only servers which have explicitly enabled the "deny-answer-aliases"
feature are at risk and disabling the feature prevents exploitation.

CVSS Score: 7.5
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

For more information on the Common Vulnerability Scoring System and
to obtain your specific environmental score please visit:
https://www.first.org/cvss/calculato...:U/C:N/I:N/A:H

Workarounds:

This vulnerability can be avoided by disabling the "deny-answer-aliases"
feature if it is in use.

Active exploits:

No known active exploits.

Solution:

Most operators will not need to make any changes unless they are
using the "deny-answer-aliases" feature (which is described in
the BIND 9 Adminstrator Reference Manual section 6.2.)
"deny-answer-aliases" is off by default; only configurations
which explicitly enable it can be affected by this defect.

If you are using "deny-answer-aliases", upgrade to the patched
release most closely related to your current version of BIND.

- 9.9.13-P1
- 9.10.8-P1
- 9.11.4-P1
- 9.12.2-P1

Quote:

Originally Posted by abga (Post 5871732)

News have arrived related to this TLBleed:
https://www.blackhat.com/us-18/brief...-is-not-enough
The video presentation (pretty bad quality):
http://www.eweek.com/security/tlblee...d-at-black-hat
And the research paper, stating that it was only tested on Intel CPUs and that the ARM Trust-Zone processes might be also vurnerable:
https://www.vusec.net/wp-content/upl...r-preprint.pdf
Quote from the Conclusion:
" In this paper, we have shown that TLB activity monitoring not only offers a practical new side channel, but also that it bypasses all the state-of-the-art cache side-channel defenses. Since the operation of the TLB is a fundamental hardware property, mitigating TLBleed is challenging. "
And the mitigation looks to be ATM disabling hyper-threading or running the sensitive process on an isolated core:
"The simplest way to mitigate TLBleed is by disabling hyperthreads or by ensuring in the operating system that sensitive processes execute in isolation on a core"
Disabling hyper-threading might have a high performance impact, up to 30% according to Wiki:
https://en.wikipedia.org/wiki/Hypert...ormance_claims

I couldn't find any position from Intel on the subject yet, but then, recalling how meltdown&spectre were initially handled (pre-disclosure), I guess it'll take some time:
https://www.theregister.co.uk/2018/0...e_cert_timing/