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

Additional exploits published for Intel (et al?) processors:

http://tinyurl.com/yclkz4l3

Quote:

All eight are essentially based on the same design problem that the "Meltdown and Specter for Dummies" section details - they are, so to speak, Specter Next Generation

The vulnerabilities aren't Meltdown and Specter, but stem from the same implementation flaws. They are unlikely to be the last.

Quote:

Originally Posted by ttk (Post 5850314)

Additional exploits published for Intel (et al?) processors:

http://tinyurl.com/yclkz4l3

The vulnerabilities aren't Meltdown and Specter, but stem from the same implementation flaws. They are unlikely to be the last.

I've read the original German article today when it appeared, meanwhile they published an official English translation:
https://www.heise.de/ct/artikel/Excl...s-4040648.html

It's all kept secret until on the 7th of May, that's the next patch day from Redmond.

P.S. There's a follow-up on the original article, which contains the official reaction (quoted) from Intel & AMD, ARM did not reply.
The original positions from Intel&AMD are to be found in English at the end of the article:
https://www.heise.de/security/meldun...n-4039302.html

A short update/follow-up on the Spectre-NG vulnerabilities:
https://www.heise.de/security/meldun...n-4043790.html

The article is only available in German and you can use a translation service on it. At least for me German is a native language and I can help with a short summary on the main points:

It's reported that Intel had asked for a postponing of the release of the technical information & patches, for at least 2 weeks.
They're planning a coordinated release of technical information for at least two of the Spectre-NG vulnerabilities together with microcode updates on the 21th of May 2018.
But not even this new date is fixed, as Intel apparently asked for another extension until on the 10th of July 2018.
The amount of affected CPUs is "enormous", covering not only the Core-i CPUs and their Xeon derivatives, at least from when they first appeared (nehalem 2010), but also Atom/Pentium/Celeron CPUs released since 2013.
For the mitigation of the more dangerous Spectre-NG vulnerabilities, mainly related to VMs, Intel is planning additional patches in the form of microcode updates + software patches for the 14th of August 2018.

I'm wondering where Heise Online took all this info and why are they the only ones owning it, pretty much all the other tech publications cite them. Personally, I trust them, I consider them serious and following (one of my daily reads) them myself for a very long tine.
https://en.wikipedia.org/wiki/Heinz_Heise

Hi,

mariadb-10.0.35 is released with many security fixes.

Quote:

Originally Posted by Daedra (Post 5853043)

Freetype 2.9.1 is released, with fixes to some vulnerabilities.

http://cve.mitre.org/cgi-bin/cvename...=CVE-2018-6942
https://sourceforge.net/projects/fre...eetype2/2.9.1/

Good luck compiling it without Windows.h.

Quote:

Originally Posted by volkerdi (Post 5853056)

Good luck compiling it without Windows.h.

Running make RC='' seems to be a usable workaround for now? I tested it and it builds.

http://lists.nongnu.org/archive/html.../msg00078.html

curl-7.60.0 is released with security fixes.

Quote:

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

curl might overflow a heap based memory buffer when closing down an FTP
connection with very long server command replies.

When doing FTP transfers, curl keeps a spare "closure handle" around
internally that will be used when an FTP connection gets shut down since the
original curl easy handle is then already removed.

FTP server response data that gets cached from the original transfer might
then be larger than the default buffer size (16 KB) allocated in the "closure
handle", which can lead to a buffer overwrite. The contents and size of that
overwrite is controllable by the server.

This situation was detected by an assert() in the code, but that was of course
only preventing bad stuff in debug builds. This bug is very unlikely to
trigger with non-malicious servers.

We are not aware of any exploit of this flaw.

INFO
----

This bug was introduced in April 2017 in [this
commit](https://github.com/curl/curl/commit/e40e9d7f0decc79) when we
introduced the use of increased buffer sizes for FTP.

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

CWE-122: Heap-based Buffer Overflow

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

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

Quote:

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

curl can be tricked into reading data beyond the end of a heap based buffer
used to store downloaded content.

When servers send RTSP responses back to curl, the data starts out with a set
of headers. curl parses that data to separate it into a number of headers to
deal with those appropriately and to find the end of the headers that signal
the start of the "body" part.

The function that splits up the response into headers is called
`Curl_http_readwrite_headers()` and in situations where it can't find a single
header in the buffer, it might end up leaving a pointer pointing into the
buffer instead of to the start of the buffer which then later on may lead to
an out of buffer read when code assumes that pointer points to a full buffer
size worth of memory to use.

This could potentially lead to information leakage but most likely a
crash/denial of service for applications if a server triggers this flaw.

We are not aware of any exploit of this flaw.

INFO
----

This bug was originally introduced in May 2003 in [this
commit](https://github.com/curl/curl/commit/b2ef79ef3d47b37) but it didn't
become a problem until we added RTSP in January 2010 in [this
commit](https://github.com/curl/curl/commit/bc4582b68a673d3).

We have only proven this to trigger with RTSP traffic even though this is code
shared with HTTP. We believe this is not a problem for HTTP transfers.

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

CWE-126: Buffer Over-read

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

- Affected versions: curl 7.20.0 to and including curl 7.59.0
- Not affected versions: curl < 7.20.0 and curl >= 7.60.0

A short update on the "SpectreNG" vulnerabilities:
Variant 3 (CVE-2017-5754)
Subvariant 3a (CVE-2018-3640)
Variant 4 (CVE-2018-3639)

Intel's announcement:
https://newsroom.intel.com/editorial...nnel-analysis/
Affected CPUs (Intel):
https://www.intel.com/content/www/us...-sa-00115.html
The German IT publication, the one that disclosed SpectreNG some weeks ago, states that Intel has already microcode updates available, but they are in beta-stage and these updates will be deployed through HW manufacturers (BIOS) as well as OS level images in the following months.(use some translation service):
https://www.heise.de/security/meldun...n-4051900.html

ARM on the subject:
https://developer.arm.com/support/ar...-vulnerability
RedHat on Variant 4:
https://access.redhat.com/security/vulnerabilities/ssbd

P.S.
A comprehensive article in English:
https://www.theregister.co.uk/2018/0...rosoft_google/

Another vector demonstrated for exploiting the Rowhammer vulnerability:

https://thehackernews.com/2018/05/re...ttack.html?m=1

Quote:

the new Rowhammer attack technique, dubbed Nethammer, can be used to execute arbitrary code on the targeted system by rapidly writing and rewriting memory used for packet processing, which would be possible only with a fast network connection between the attacker and victim.

Git 2.17.1 fixes CVE-2018-11233 / CVE-2018-11235 (potential aribtrary code execution).

it has been pushed to current on May 31

libgcrypt 1.7.10 and 1.8.3 are released with security fixes :

https://gnupg.org/ftp/gcrypt/libgcry...10.tar.bz2.sig
https://gnupg.org/ftp/gcrypt/libgcry...1.7.10.tar.bz2
https://gnupg.org/ftp/gcrypt/libgcry....3.tar.bz2.sig
https://gnupg.org/ftp/gcrypt/libgcry...-1.8.3.tar.bz2

Quote:

The GnuPG Project is pleased to announce the availability of Libgcrypt
versions 1.8.3 and 1.7.10. These releases mitigate a novel side-channel
attack on ECDSA signatures and also bring fixes for a few other bugs.

Libgcrypt is a general purpose library of cryptographic building blocks.
It is originally based on code used by GnuPG. It does not provide any
implementation of OpenPGP or other protocols. Thorough understanding of
applied cryptography is required to use Libgcrypt.

Noteworthy changes in version 1.8.3
===================================

- Use blinding for ECDSA signing to mitigate a novel side-channel
attack. [#4011,CVE-2018-0495]

- Fix incorrect counter overflow handling for GCM when using an IV
size other than 96 bit. [#3764]

- Fix incorrect output of AES-keywrap mode for in-place encryption
on some platforms.

- Fix the gcry_mpi_ec_curve_point point validation function.

- Fix rare assertion failure in gcry_prime_check.

Release info at <https://dev.gnupg.org/T4016>.

We also released a new version of the older 1.7 branch with similar
fixes.

Comments on the attack
======================

Details on CVE-2018-0495 can be found in the paper "Return of the Hidden
Number Problem" which can be downloaded from the advisory page
<https://www.nccgroup.trust/us/our-research/technical-advisory-return-of-the-hidden-number-problem/>.
See <https://dev.gnupg.org/T4011> for a timeline.

One user of Libgcrypt is GnuPG, thus a quick comment: GnuPG does not use
the vulenrable ECDSA signatures by default. Further, it is much harder
to mount such an attack against an offline protocol like OpenPGP than
against online protocols like TLS. Anyway, we also released a new
Windows installer for GnuPG 2.2.8 featuring the fixed Libgcrypt version.
That installer is linked from the usual download page and a new Gpg4win
version will be released soon.

Another episode in the series of Intel CPU bugs - LazyFP vulnerability: Exploiting lazy FPU state switching, affecting apparently only Intel processors.
Intel SA-0014
CVE-2018-3665
https://www.intel.com/content/www/us...-sa-00145.html
https://cve.mitre.org/cgi-bin/cvenam...=CVE-2018-3665

More technical details:
http://blog.cyberus-technology.de/po...erability.html

Quote:

Mitigation
Using GNU/Linux with kernel versions >= 3.7, this attack can be mitigated by adding “eagerfpu=on” to the kernel’s boot parameters. We are not aware of a workaround for older versions. For all other operating systems: install the official update(s) from the vendor.

https://xenbits.xen.org/xsa/advisory-267.html

Quote:

Only x86 processors are vulnerable. ARM processors are not known to be
affected.
Only Intel Core based processors (from at least Nehalem onwards) are
potentially affected. Other processor designs (Intel Atom/Knights
range), and other manufacturers (AMD) are not known to be affected.

https://www.zdnet.com/article/anothe...le-lazy-state/

Quote:

Other operating systems believed to be safe are any Linux version using the 2016's Linux 4.9 or newer kernel. The Linux kernel developers are patching older kernels

P.S.
The Linux Kernel patch that defaults eagerfpu=on on all CPUs, thus mitigating this issue, is applied starting with the kernel version v4.6-rc1 :
https://github.com/torvalds/linux/co...c557d997d46a19

linux-4.4.138 includes a fix for CVE-2018-3665: "x86/fpu: Disable AVX when eagerfpu is off"

https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.138

I wouldn't mind an official 4.4.138 patch for 14.2 (which would likely also be applicable to 14.1 -- I've been updating my 14.1 systems with 14.2 kernels for a while now).