- openSUSE Security

[opensuse-security] update for nvidia drivers?
by Mathias Homann 25 Jun '20

25 Jun '20

Hi, this just in: https://www.heise.de/security/meldung/Mehrere-Sicherheitsluecken-in-Grafikk… https://nvidia.custhelp.com/app/answers/detail/a_id/5031/kw/ Security%20Bulletin Linux users are adwised to update to 450.51 as soon as possible... so how soon IS possible for openSUSE? Cheers MH -- Mathias Homann Mathias.Homann(a)openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy(a)tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

2 2

[opensuse-security] update for git to 2.26.1 for all openSUSE versions?
by Mathias Homann 15 Apr '20

15 Apr '20

Hi all, see https://bitbucket.org/blog/git-vulnerability-in-multiple-versions-including… git 2.26.1 is already in https://build.opensuse.org/package/show/ devel:tools:scm/git so it should be easy enough to provide that as update for Leap and SLE. Cheers MH -- Mathias Homann Mathias.Homann(a)openSUSE.org Jabber (XMPP): lemmy(a)tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

2 1

[opensuse-security] Installing the Shorewall lite firewall is not possible. What is wrong?
by JadoNena 03 Apr '20

03 Apr '20

Helo, I am hoping to install Shorewall lite firewall on the remote VM. On it I am running openSUSE Leap 15.1 for production. It is just new instaled. I added the most modern version repositorie zypper ar https://download.opensuse.org/repositories/security:/netfilter/openSUSE_Lea… Security zypper install shorewall-lite shorewall-init When I install it zypper install shorewall-lite shorewall-init there is this problem Problem: shorewall-init-5.2.4-242.1.noarch requires shorewall >= 5.0, but this requirement cannot be provided not installable providers: shorewall-5.1.12.4-lp151.2.24.noarch[Leap151OSS] shorewall-5.2.4-lp151.238.1.noarch[Security] Solution 1: do not install shorewall-lite-5.2.4-242.1.noarch Solution 2: do not install shorewall-init-5.2.4-242.1.noarch Solution 3: break shorewall-init-5.2.4-242.1.noarch by ignoring some of its dependencies I do not understand it. What do I do that is the problem? Thank you for the help, Janek -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

3 4

[opensuse-security] pam-config and sssd
by Markus Gaugusch 31 Mar '20

31 Mar '20

Hi all, I'm using openSUSE Leap 15.1 on a machine which was previously configured with samba/winbind for enumeration of users from a Microsoft AD. It was also possible for those users to login to the machine. After upgrades and changes to the domain controllers (Windows Server 2019), I got lots of winbind errors in the logs. I decided to do a fresh start and use sssd instead of winbind. I configured it using realmd (realmd join mydomain.xxx --user myadminuser), and it worked quite well. I also configured ssh login in the following way (/etc/pam.d): (please forgive the strange stuff in the auth section, but after some fighting it worked :)) sshd: auth requisite pam_nologin.so auth required pam_env.so auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet auth [default=1 success=ok] pam_localuser.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet auth sufficient pam_sss.so account requisite pam_nologin.so account include common-account <===== check this [... password, session omitted ...] common-account: account required pam_unix.so try_first_pass account sufficient pam_sss.so forward_pass Now I installed recent upgrades, which obviously executed pam-config. The common-account was updated and contained only the following lines: account requisite pam_unix.so try_first_pass account sufficient pam_localuser.so account required pam_sss.so use_first_pass My users could no longer login, because the pam_unix requisite kills the login before pam_sss is even called. I checked the source of pam-config and it is doing exactly that: https://github.com/SUSE/pam-config/blob/master/src/mod_pam_unix.c#L64 case ACCOUNT: if (with_krb5 || with_ldap || with_lum || with_winbind || with_sss) fprintf (fp, "account\trequisite\tpam_unix.so\t"); else fprintf (fp, "account\trequired\tpam_unix.so\t"); break; QUESTION: Why does pam-config use account "requisite" for pam_unix.so in case of pam_sss presence? I'd expect "required", and that also works if I change it manually. But unfortunately, my changes are lost every time pam-config is run again ... Also, pam_sss should be "sufficient" afterwards, not "required" ... (At least that works, and while I've learned a lot about PAM during the last days, I'm not there yet I think :) thanks! Markus -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

1 0

[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

[opensuse-security] BZip2 Update for CVE-2019-12900?
by Markus Gaugusch 08 Jul '19

08 Jul '19

Hi, I'm using Amavis and I'm worried about CVE-2019-12900. SuSE classifies it as local only (https://www.suse.com/de-de/security/cve/CVE-2019-12900/), which does not seem to be appropriate to me, especially when I'm using Amavis. When will this be fixed? thanks! Markus -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

2 1

[opensuse-security] Re: [opensuse-virtual] How to correctly configure mitigation of CVE-2018-3646 'Foreshadow-NG (VMM)' on Xen Dom0 host?
by PGNet Dev 15 Apr '19

15 Apr '19

On 4/15/19 10:49 AM, Dario Faggioli wrote: > On Mon, 2019-04-15 at 09:59 -0700, PGNet Dev wrote: > It's pretty much what we do by default, which might be seen as a good > sign, I guess. *Suse also enables "IBPB" by default. is that (still) correct? Which I'd like to NOT take the purported ~20% performance hit for, and believe I've correctly (?) DISabled with adding: spectre_v2=retpoline,generic to my grub config's kernel command line > Well, not quite. :-/ > > In fact, this is from inside a guest. In order for things to be 100% > safe, hyperthreading should be disabled at the _host_ level, which is > something that the guest can't know. > > Actually, the guest can't know for sure whether or not the underlying > host it is running on has L1D flush supported and enabled either. > > So, I think it is calling it "NOT VULNERABLE" on the ground, e.g., that > , as it says, "this system is not running an hypervisor". But that is > going to be true for any VM, unless one is using nested virtualization. > > If that's the case, the whole 'Foreshadow-NG (VMM)' block appears to be > rather bogous... but I really want to speak only after having checked > the code. :-) Understood. Also, I *did* see a KVM host-side change (namely, an upgrade to a fully patched Host) that switched the reporting of Variant 3a & 4 vulnerabilities from VULNERABLE ==> NOT VULNERABLE, in the guest. Which I believe is expected. -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

1 0

[opensuse-security] Re: [opensuse-virtual] How to correctly configure mitigation of CVE-2018-3646 'Foreshadow-NG (VMM)' on Xen Dom0 host?
by PGNet Dev 15 Apr '19

15 Apr '19

On 4/15/19 9:34 AM, Dario Faggioli wrote: > point is this: > - exploiting L1TF, it may be possible to read the host physical RAM > from inside a VM. This means malicious code running inside a VM can > read the memory of other applications inside the same VM, of other > VMs and also of the hypervisor. > It is not entirely trivial, even without mitigations applied, but > it's possible, and proofs of contept do exist; > - for Xen PV guests, if the guest has "PTE Inversion" and Xen has > pv-l1tf enabled, the problem is fully mitigated; > - for Xen HVM guests or KVM guests, on system without hyperthreading > (or with hyperthreading properly disabled), if L1D flush is supported > (by hardware and hypervisor) and enabled, the problem is fully > mitigated; > - for Xen HVM guests or KVM guests, on system with hypetrheading, > the problem can't be fully mitigated. That's really clear. And the 1st time I've read it all, so succinctly stated, in one place. It would, IMO, be very helpful on a 'Spectre on *Suse' doc/wiki page. atm, on this particular host, my Xen cmd line includes: spec-ctrl=ssbd,l1d-flush=true pv-l1tf=dom0=true,domu=true smt=true which may, or not, be overkill/risky; still need to do some reading up on the relative merits. > For KVM guests and Xen HVM guests, can you paste the full output of the > section "CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'" ? Don't have a Xen HVM up right at the moment. For KVM guest (@ Linode, fwiw), spectre-meltdown-checker.sh ... CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault' * Information from the /sys interface: * This system is a host running an hypervisor: NO * Mitigation 1 (KVM) * EPT is disabled: N/A (the kvm_intel module is not loaded) * Mitigation 2 * L1D flush is supported by kernel: YES (found flush_l1d in kernel image) * L1D flush enabled: UNKNOWN (unrecognized mode) * Hardware-backed L1D flush supported: NO (flush will be done in software, this is slower) * Hyper-Threading (SMT) is enabled: NO > STATUS: NOT VULNERABLE (this system is not running an hypervisor) > SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK IIUC from your comments above, the apparently *dis*abled SMT hyperthreading leads, in this case, to the mitigation STATUS ==> NOT VULNERABLE -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

1 0

[opensuse-security] Re: [opensuse-virtual] How to correctly configure mitigation of CVE-2018-3646 'Foreshadow-NG (VMM)' on Xen Dom0 host?
by PGNet Dev 15 Apr '19

15 Apr '19

On 4/15/19 3:08 AM, Dario Faggioli wrote: >> >> Not sure yet why I'm seeing UNKNOWN here, >> > I haven't checked the source code but that's, most likely, because the > checked tries to figure out whether the Linux kernel, on top of the > hardware where it's running, has the capability to --let's say-- issue > the L1D-Flush instructions, without taking into account the fact that > you may be running inside a Xen (PV) guest. > > In fact, if you run this check from within a Xen dom0 (which you are, > aren't you?), Yes, I am exec'ing this at the Dom0 shell. > you're inside a PV-guest, on top of Xen, and a PV-guest > can't do the L1D flush (basically because that would be pointless for > it). Which, IIUC, would be the case for ANY Xen PV-guest as well? I do note that, cursorily testing the checker in a (hosted elsewhere) KVM guest, I see: STATUS: NOT VULNERABLE (this system is not running an hypervisor) which is a different result, though still in a Hypervisor-host's VM guest ... > So, this is all technically correct. > >> (2) Hardware-backed L1D flush supported: NO >> > Again, this is correct. As far as the dom0 PV kernel knows and see, the > hardware is not capable of that. That's because the view of the > hardware it has is filtered by Xen, and Xen let it believe (and that's > on purpose) that this is the situation. > >> even though >> >> (XEN) [00000028c19f6e50] Hardware features: IBRS/IBPB STIBP >> L1D_FLUSH SSBD >> > Exactly, and this is what is important to have in the logs and to > check, in order to know whether you have the L1TF mitigations in place. To be clear, is the *existence* of "L1D_FLUSH" in that 'Hardware Features:' log line evidence that the feature is, in fact, *in use* as a Spectre mitigation? >> What's missing in my config to mitigate/remove the CVE-2018-3646 >> vulnerability? >> > There's nothing you're missing, as far as I can tell. What the problem > seems to be, is that spectre-and-meltdown-checker.sh does not treat the > case of this check being made within a Xen (PV) guest properly. > > I'll check whether this is actually the case, and I'll to see about > fixing that, as soon as I find a minute. Thanks. > Oh, BTW, you know this already, but let me also add this: if you are > running only PV guests, with the settings you've shown you are using, > you are indeed safe against L1TF. Yep. And I do ... _mostly_. On occassion, I do run HVM guest, so fussing with this. Generally, I'd like to get a handle on all the mitigations, in all use cases, and then make any decisions about performance-vs-security ... > If you are running HVM guests too, the only way to be totally and > absolutely safe is, for now, to disable hyperthreading (and that's the > case for KVM too, FWIW). Sure. With the available 'compromise' of leaving it enabled, if one makes the call that the host/guest are under sufficiently secure control ... -- To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org

1 0