openSUSE Security February 2020

security@lists.opensuse.org

5 participants
2 discussions

[opensuse-security] need for clarifications between Secure Boot and Trusted Boot
by jc＠phocean.net 18 Feb '20

18 Feb '20

Hello here, I just found this post about a feature that I was not aware of, and seems to result from a patch that is very specific to openSUSE, namely Trusted Boot: https://lizards.opensuse.org/2016/05/18/highlights-of-yast-development-spri… 1) About Secure Boot I have been using SecureBoot for a while, and here is my understanding of Secure Boot in openSUSE: - the root of trust is the UEFI ; - it does use the TPM for cryptographic measurements ; - Shim in the EFI partition is the first component to check the signature of grub, then subsequently the chain continues from the kernel up to the modules. It works pretty well, except that most distributions have an implementation flaw (e.g Ubuntu, Fedora): as long as /boot has not been encrypted, an attacker with physical access to the machine can alter the initrd, do nasty stuff (like hijacking the user encryption password) and then proceed with the boot execution normally. I can confirm this flaw for sure as this is something that we have tested at my work. In openSUSE, /boot is encrypted by default and Grub has been patched to prompt for decryption, so this is a good mitigation against these "evil maid attacks". Overall, did I get it correctly ? 2) About Trusted boot The documentation is sparse so I am confused on how it compares with the SecureBoot implementation above. My understanding is that it's exactly the same, except that it's some kind of legacy support for Grub and legacy BIOS, without UEFI. It's not clear here what's the root of trust: I guess this can only be Grub itself, storing measurements in the TPM. Again, thank you for telling me if I am correct or wrong... Following your feedback, it might be a good idea that I write some stuff in the wiki or/and my blog to clarify all this. Thank you ! Best regards, Jean-Christophe -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

3 3

[opensuse-security] patch openSUSE-2019-1806 fails to mitigate CVE-2018-12126/CVE-2018-12130/CVE-2018-12127/CVE-2019-11091 ?
by PGNet Dev 13 Feb '20

13 Feb '20

This security update https://lists.opensuse.org/opensuse-security-announce/2019-07/msg00052.html addresses Four new speculative execution information leak issues have been identified in Intel CPUs. (bsc#1111331) - CVE-2018-12126: Microarchitectural Store Buffer Data Sampling (MSBDS) - CVE-2018-12127: Microarchitectural Fill Buffer Data Sampling (MFBDS) - CVE-2018-12130: Microarchitectural Load Port Data Samling (MLPDS) - CVE-2019-11091: Microarchitectural Data Sampling Uncacheable Memory (MDSUM) These updates contain the CPU Microcode adjustments for the software mitigations. to be installed with zypper in -t patch openSUSE-2019-1806=1 here, running lsb_release -rd Description: openSUSE Leap 15.1 Release: 15.1 uname -rm 5.5.2-25.g994cf1f-default x86_64 rpm -qa | egrep "ucode-intel|firmware-intel" ucode-intel-20191115-lp151.3.9.x86_64 kernel-firmware-intel-20200122-36.2.noarch on an old, but otherwise functional, laptop, cat /proc/cpuinfo | grep -i "model name" model name : Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz with mitigations enabled with, cat /proc/cmdline BOOT_IMAGE=/vmlinuz-5.5.2-25.g994cf1f-default ... mitigations=auto,nosmt ... and zypper in -t patch openSUSE-2019-1806=1 Loading repository data... Reading installed packages... 'patch:openSUSE-2019-1806 = 1' is already installed. Resolving package dependencies... Nothing to do. a check with spectre-meltdown-checker.sh --version Spectre and Meltdown mitigation detection tool v0.43 returns ... CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)' * Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled) * Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image) * Kernel mitigation is enabled and active: NO * SMT is either mitigated or disabled: YES > STATUS: VULNERABLE (Your kernel supports mitigation, but your CPU microcode also needs to be updated to mitigate the vulnerability) CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)' * Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled) * Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image) * Kernel mitigation is enabled and active: NO * SMT is either mitigated or disabled: YES > STATUS: VULNERABLE (Your kernel supports mitigation, but your CPU microcode also needs to be updated to mitigate the vulnerability) CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)' * Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled) * Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image) * Kernel mitigation is enabled and active: NO * SMT is either mitigated or disabled: YES > STATUS: VULNERABLE (Your kernel supports mitigation, but your CPU microcode also needs to be updated to mitigate the vulnerability) CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)' * Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled) * Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image) * Kernel mitigation is enabled and active: NO * SMT is either mitigated or disabled: YES > STATUS: VULNERABLE (Your kernel supports mitigation, but your CPU microcode also needs to be updated to mitigate the vulnerability) ... and cat /sys/devices/system/cpu/vulnerabilities/mds Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled what additional mitigation, &/or specific microcode update is required to complete the mitigations? -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

3 5

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

openSUSE Security February 2020