LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 06-20-2018, 06:43 AM   #751
elcore
Senior Member
 
Registered: Sep 2014
Distribution: Slackware
Posts: 1,747

Rep: Reputation: Disabled

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)

Last edited by elcore; 06-20-2018 at 06:46 AM.
 
Old 06-25-2018, 10:10 AM   #752
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
Quote:
Originally Posted by elcore View Post
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
 
2 members found this post helpful.
Old 07-11-2018, 12:13 AM   #753
Thom1b
Member
 
Registered: Mar 2010
Location: France
Distribution: Slackware
Posts: 476

Rep: Reputation: 333Reputation: 333Reputation: 333Reputation: 333
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]

Last edited by Thom1b; 07-11-2018 at 01:23 AM. Reason: Wrong version : s/9.11.4/9.10.8
 
1 members found this post helpful.
Old 07-11-2018, 01:26 AM   #754
Thom1b
Member
 
Registered: Mar 2010
Location: France
Distribution: Slackware
Posts: 476

Rep: Reputation: 333Reputation: 333Reputation: 333Reputation: 333
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
 
2 members found this post helpful.
Old 07-11-2018, 04:24 PM   #755
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
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
 
3 members found this post helpful.
Old 07-16-2018, 01:18 PM   #756
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-15.0
Posts: 11,044

Rep: Reputation: Disabled
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.

Last edited by Didier Spaier; 07-16-2018 at 01:48 PM.
 
1 members found this post helpful.
Old 07-24-2018, 01:59 PM   #757
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
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/
 
1 members found this post helpful.
Old 08-03-2018, 11:49 PM   #758
Thom1b
Member
 
Registered: Mar 2010
Location: France
Distribution: Slackware
Posts: 476

Rep: Reputation: 333Reputation: 333Reputation: 333Reputation: 333
mariadb-10.0.36 is released with many security fixes.
https://mariadb.com/kb/en/mdb-10036-rn/
 
1 members found this post helpful.
Old 08-07-2018, 06:09 AM   #759
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
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
 
Old 08-07-2018, 06:22 AM   #760
ponce
LQ Guru
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 7,060

Rep: Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139
Quote:
Originally Posted by abga View Post
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
this is actually patched already in Slackware current (the only one to which this applies) since the update to kernel 4.14.59.
 
Old 08-07-2018, 06:33 AM   #761
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
Quote:
Originally Posted by ponce View Post
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

Last edited by abga; 08-07-2018 at 07:27 AM. Reason: correction - 23 Jul 2018
 
Old 08-07-2018, 07:00 AM   #762
ponce
LQ Guru
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 7,060

Rep: Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139Reputation: 4139
Quote:
Originally Posted by abga View Post
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.
 
Old 08-07-2018, 07:34 AM   #763
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
Quote:
Originally Posted by ponce View Post
...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.
 
2 members found this post helpful.
Old 08-09-2018, 12:48 AM   #764
Thom1b
Member
 
Registered: Mar 2010
Location: France
Distribution: Slackware
Posts: 476

Rep: Reputation: 333Reputation: 333Reputation: 333Reputation: 333
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
 
2 members found this post helpful.
Old 08-11-2018, 09:06 AM   #765
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,634

Rep: Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929Reputation: 929
Quote:
Originally Posted by abga View Post
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
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/
 
5 members found this post helpful.
  


Reply

Tags
exploit, security, slackware


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[Slackware Security]: Some pending vulnerabilities... mancha Slackware 7 08-22-2013 09:08 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 03:02 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration