[Slackware security] vulnerabilities outstanding 20140101

abga · 01-28-2020, 03:39 PM

Those of you fellow Slackers running on newer Intel CPUs (manufactured since 2015, apparently) thinking that by applying all the latest microcodes and kernel patches, your systems are safe now, think again ....
The latest microcode patches Intel provided are not fully mitigating the already discovered CPU flaws.

https://www.intel.com/content/www/us...-sa-00329.html

CVE-2020-0549 - called CacheOut by the University of Michigan and L1DES (L1D Eviction Sampling) by Intel
https://cacheoutattack.com/
https://mdsattacks.com/#ridl-nng
https://software.intel.com/security-...ction-sampling

CVE-2020-0548 - called VRS (Vector Register Sampling)
https://software.intel.com/security-...ister-sampling

There are no mitigations available ATM, microcode updates should fix them both. No info about future kernel patches.

Some articles on the subject:
https://www.wired.com/story/intel-zo...ive-execution/
https://www.phoronix.com/scan.php?pa...e-Data-Leakage

GazL · 01-28-2020, 04:19 PM

Quote:

Originally Posted by abga

Those of you fellow Slackers running on newer Intel CPUs (manufactured since 2015, apparently) thinking that by applying all the latest microcodes and kernel patches, your systems are safe now, think again ....

I don't believe anyone is under that delusion any more. Speculative execution is the gift that keeps on giving, and is likely to continue to do so for a good number of years yet.

abga · 01-28-2020, 11:23 PM

And when you think of it, Linus called the first Intel patches "COMPLETE AND UTTER GARBAGE".
https://lkml.org/lkml/2018/1/21/192
Poor guy was punished and had to abide to this:
https://git.kernel.org/pub/scm/linux...4093c54469c11f
But he deserved it, he was "utterly" wrong in the first place, forgot to add the word PERPETUAL in front of his original expression

I'm only running on Intels and never considered AMD in the last 15 years or more. Will start to look more closely at their mobile CPUs from now on, since I'm loosing confidence in Intel's commitment in properly resolving their issues.
My last experience with AMD on laptops was: really bad thermal issues, overheating, CPUs literally burning out (including MB), they wouldn't last more than 1-2 years of normal usage. I hope that changed now.

abga · 03-10-2020, 08:24 PM

New vulnerability published affecting Intel SGX enabled CPUs. Firmware (microcode update) mitigation will be available and binutils is patching itself:
https://sourceware.org/pipermail/bin...ch/110175.html

https://lviattack.eu/
"LVI is a new class of transient-execution attacks exploiting microarchitectural flaws in modern processors to inject attacker data into a victim program and steal sensitive data and keys from Intel SGX, a secure vault in Intel processors for your personal data."

Intel's advisory:
https://www.intel.com/content/www/us...-sa-00334.html

CVE entry:
https://cve.mitre.org/cgi-bin/cvenam...=CVE-2020-0551

TracyTiger · 04-05-2020, 12:48 PM

It appears that Chrome (Chromium) has some vulnerabilities. In that last couple of days (March 31st) it has been recommended to upgrade to 80.0.3987.162 due to several important security issues.

https://www.us-cert.gov/ncas/current...updates-chrome

I pulled down Alien Bob's Chromium a couple of weeks ago and it was at 80.0.3987.149.

Those that follow Chrome more closely can add detail about these vulnerabilities. I only use Alien Bob's Chromium for websites that demand its features. (Thanks Eric!)

Although not a Slackware specific issue I'm posting this to inform members of this forum.

EDIT: More detail...

https://www.cisecurity.org/advisory/...tion_2020-044/

abga · 06-10-2020, 05:42 PM

A new security hole in some of the Intel Core i7, Core i9 and Xeon CPUs, called SRBDS, CVE-2020-0543.
Mitigated apparently only through microcode updates.
Details (I stopped analyzing them, don't really feel the need to become an expert in CPU design... ):
https://www.vusec.net/projects/crosstalk/
https://www.intel.com/content/www/us...-sa-00320.html

Extra, the usual AMT, plus some SSD, BIOS and "Innovation Engine Build and Signing Tool" (interesting name):
https://www.intel.com/content/www/us...-sa-00295.html
https://www.intel.com/content/www/us...-sa-00266.html
https://www.intel.com/content/www/us...-sa-00322.html
https://www.intel.com/content/www/us...-sa-00366.html

P.S. Actually, according to Intel, many more CPU families are affected by the vulnerability. I was only reading the vusec article when I composed the post.
Full list here:
https://software.intel.com/security-...duct-cpu-model

teoberi · 06-11-2020, 12:31 AM

Quote:

Originally Posted by abga

A new security hole in some of the Intel Core i7, Core i9 and Xeon CPUs, called SRBDS, CVE-2020-0543.
Mitigated apparently only through microcode updates.

Code:

./spectre-meltdown-checker.sh -v

Quote:

CVE-2020-0543 aka 'Special Register Buffer Data Sampling (SRBDS)'
* SRBDS mitigation control is supported by the kernel: NO
* SRBDS mitigation control is enabled and active: NO (SRBDS not found in sysfs hierarchy)
> STATUS: NOT VULNERABLE (Your microcode is up to date for SRBDS mitigation control. The kernel needs to be updated)

And after updating the kernel:

Quote:

CVE-2020-0543 aka 'Special Register Buffer Data Sampling (SRBDS)'
* Mitigated according to the /sys interface: YES (Mitigation: Microcode)
* SRBDS mitigation control is supported by the kernel: YES (found SRBDS implementation evidence in kernel image. Your kernel is up to date for SRBDS mitigation)
* SRBDS mitigation control is enabled and active: YES (Mitigation: Microcode)
> STATUS: NOT VULNERABLE (Your microcode and kernel are both up to date for SRBDS mitigation control. Mitigation is enabled)

abga · 06-11-2020, 05:03 AM

Quote:

Originally Posted by teoberi

[CODE]
And after updating the kernel:

Thanks for the details, didn't know that the kernel also has its own mitigation part.
And, I suppose you're referring to 5.4.46. That contains :

Quote:

x86/speculation: Add Special Register Buffer Data Sampling (SRBDS) mitigation

commit 7e5b3c267d256822407a22fdce6afdf9cd13f9fb upstream

https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.46

Whereas, for the stable Slackware 14.2, the 4.4.217 kernel doesn't appear to contain the SRBDS code yet, but only 4.4.227
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.227

gegechris99 · 06-11-2020, 04:36 PM

Quote:

Originally Posted by abga

Thanks for the details, didn't know that the kernel also has its own mitigation part.

This is not really a kernel mitigation per se. Kernel 5.4.46 offers the administrator the possibility to disable the microcode SRBDS mitigation if it leads to performance issues.

Quote:

x86/speculation: Add Special Register Buffer Data Sampling (SRBDS) mitigation
commit 7e5b3c267d256822407a22fdce6afdf9cd13f9fb upstream

SRBDS is an MDS-like speculative side channel that can leak bits from the
random number generator (RNG) across cores and threads. New microcode
serializes the processor access during the execution of RDRAND and
RDSEED. This ensures that the shared buffer is overwritten before it is
released for reuse.

While it is present on all affected CPU models, the microcode mitigation
is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the
cases where TSX is not supported or has been disabled with TSX_CTRL.

The mitigation is activated by default on affected processors and it
increases latency for RDRAND and RDSEED instructions. Among other
effects this will reduce throughput from /dev/urandom.

* Enable administrator to configure the mitigation off when desired using
either mitigations=off or srbds=off.

* Export vulnerability status via sysfs

Also SRBDS vulnerability status can be checked with:

Code:

$cat /sys/devices/system/cpu/vulnerabilities/srbds

The output could be one of the following:

Code:

"Vulnerable"
"Vulnerable: No microcode"
"Mitigation: Microcode"
"Mitigation: TSX disabled"
"Unknown: Dependent on hypervisor status"

Didier Spaier · 07-29-2020, 12:32 PM

Quoting a message from Daniel Kiper on the grub-devel mailing list:

Quote:

We have recently been made aware of a problem with GRUB2 by security research firm Eclypsium that allows a bad actor to circumvent UEFI Secure Boot. Normally, when Secure Boot is enabled, only modules [1] that have a valid signature can be loaded. The bug allows this to be circumvented and allow a module to be loaded that is not signed and therefore breaks the chain of trust that Secure Boot is supposed to guarantee.

This is not a concern for most Slackware users as Slackware doesn't allow booting with Secure Boot enabled out of the box, however it is possible to enable this feature as documented in this article on SlackDocs.

So if you enable Secure Boot read the message from Daniel.

PS I assume that all the 28 patches will be applied in grub-2.06, so just upgrading will address the mentioned CVEs. As an aside work on this issue probably delayed the release of this new version, meanwhile several non-security patches wait to be committed but the first RC can now appear within a few weeks, I think.

EDIT: good guess

Le 29/07/2020 à 19:46, Daniel Kiper a écrit :
> I think this link [1] will explain my long absence... Sorry about that.
>
> I am going to go back to GRUB work next week. I will triage all the patches
> and take all (obvious) fixes. Then I will release rc1 ASAP... All new features
> will be taken after 2.06 release.
>
> Daniel
>
> [1] https://lists.gnu.org/archive/html/g.../msg00034.html

PPS The scope of this vulnerability is a lot wider than only GRUB2 as it can encompass a lot of systems using it or not to boot, including Windows. Read There’s a Hole in the Boot to know why and how.

cwizardone · 07-31-2020, 09:44 AM

There appears to be some serious security issues with xorg.

https://www.phoronix.com/scan.php?pa...CVE-2020-14344

Quote:

X.Org's Latest Security Woes Are Bugs In LibX11, Xserver
Written by Michael Larabel in X.Org on 31 July 2020 at 09:54 AM EDT.

The X.Org/X11 Server has been hit by many security vulnerabilities over the past decade as security researchers eye more open-source software. Some of these vulnerabilities date back to even the 80's and 90's given how X11 has built up over time. The X.Org Server security was previously characterized as being even worse than it looks while today the latest vulnerabilities have been made public.

CVE-2020-14344 is now public and covers multiple integer overflows and signed/unsigned comparison issues within the X Input Method implementation in the libX11 library. These issues can lead to heap corruption when handling malformed messages from an input method.

Several patches are now in libX11 Git for addressing these overflows and bad sign comparisons. LibX11 1.6.10 will be released shortly with these fixes.

More details on today's disclosure via the xorg-devel list.

Update: Further security issues are also being made public today... CVE-2020-14347 is public too as a bug in the pixmap data code leading to uninitialized heap memory being leaked to clients. In turn when paired with other flows and running the xorg-server as root could potentially lead to privilege escalation. X.Org Server 1.20.9 to be released soon with this fix, which was discovered as part of the Trend Micro Zero Day Initiative.

mats_b_tegner · 09-03-2020, 02:07 PM

https://lists.gnupg.org/pipermail/gn...q3/000448.html
https://dev.gnupg.org/T5050
https://www.gnupg.org/ftp/gcrypt/gnu...2.2.23.tar.bz2
https://www.gnupg.org/ftp/gcrypt/gnu...23.tar.bz2.sig

cwizardone · 10-20-2020, 06:12 AM

FreeType 2.10.4, is now available.

Quote:

....."This is an emergency release, fixing a severe vulnerability in embedded PNG bitmap handling...All users should update immediately."

https://www.freetype.org/

https://sourceforge.net/projects/fre...etype2/2.10.4/

Quote:

CHANGES BETWEEN 2.10.3 and 2.10.4
I. IMPORTANT BUG FIXES
- A heap buffer overflow has been found in the handling of embedded
PNG bitmaps, introduced in FreeType version 2.6.

https://cve.mitre.org/cgi-bin/cvenam...CVE-2020-15999

If you use option FT_CONFIG_OPTION_USE_PNG you should upgrade
immediately.
Source: README, updated 2020-10-20

The tarball, http://downloads.sourceforge.net/fre...-2.10.4.tar.xz

cwizardone · 11-10-2020, 08:26 PM

If you are running an Intel processor you might wnat to read this post in the kernel thread,
https://www.linuxquestions.org/quest...ml#post6184145

mats_b_tegner · 11-20-2020, 02:06 PM

Mutt 2.0.2 was released on November 20, 2020. This is an important bug-fix release, addressing CVE-2020-28896.
https://gitlab.com/muttmua/mutt/-/co...2863756ebbf59a
https://gitlab.com/muttmua/mutt/raw/stable/UPDATING
ftp://ftp.mutt.org/pub/mutt/mutt-2.0.2.tar.gz