SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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)
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)
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
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.
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.
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/
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
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
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
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 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.
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.
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/
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.