December 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1234586] New: VUL-0: CVE-2024-45337: caddy: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1234586 Bug ID: 1234586 Summary: VUL-0: CVE-2024-45337: caddy: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other URL: https://smash.suse.de/issue/432234/ OS: Other Status: NEW Whiteboard: CVSSv3.1:SUSE:CVE-2024-45337:8.1:(AV:N/AC:H/PR:N/UI:N/ S:U/C:H/I:H/A:H) Severity: Normal Priority: P5 - None Component: Security Assignee: alexandre.vicenzi(a)suse.com Reporter: andrea.mattiazzo(a)suse.com QA Contact: security-team(a)suse.de Blocks: 1234482 Target Milestone: --- Found By: --- Blocker: --- Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-45337 https://www.cve.org/CVERecord?id=CVE-2024-45337 https://github.com/golang/crypto/commit/b4f1988a35dee11ec3e05d6bf3e90b695fb… https://go.dev/cl/635315 https://go.dev/issue/70779 https://groups.google.com/g/golang-announce/c/-nPEi39gI4Q/m/cGVPJCqdAQAJ https://pkg.go.dev/vuln/GO-2024-3321 http://www.openwall.com/lists/oss-security/2024/12/11/2 https://bugzilla.redhat.com/show_bug.cgi?id=2331720 https://github.com/CVEProject/cvelistV5/blob/main//cves/2024/45xxx/CVE-2024… -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1234583] New: VUL-0: CVE-2024-45337: chezmoi: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1234583 Bug ID: 1234583 Summary: VUL-0: CVE-2024-45337: chezmoi: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other URL: https://smash.suse.de/issue/432234/ OS: Other Status: NEW Whiteboard: CVSSv3.1:SUSE:CVE-2024-45337:8.1:(AV:N/AC:H/PR:N/UI:N/ S:U/C:H/I:H/A:H) Severity: Normal Priority: P5 - None Component: Security Assignee: filippo.bonazzi(a)suse.com Reporter: andrea.mattiazzo(a)suse.com QA Contact: security-team(a)suse.de Blocks: 1234482 Target Milestone: --- Found By: --- Blocker: --- Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-45337 https://www.cve.org/CVERecord?id=CVE-2024-45337 https://github.com/golang/crypto/commit/b4f1988a35dee11ec3e05d6bf3e90b695fb… https://go.dev/cl/635315 https://go.dev/issue/70779 https://groups.google.com/g/golang-announce/c/-nPEi39gI4Q/m/cGVPJCqdAQAJ https://pkg.go.dev/vuln/GO-2024-3321 http://www.openwall.com/lists/oss-security/2024/12/11/2 https://bugzilla.redhat.com/show_bug.cgi?id=2331720 https://github.com/CVEProject/cvelistV5/blob/main//cves/2024/45xxx/CVE-2024… -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1234605] Userspace crashes on parallels VM
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1234605 https://bugzilla.suse.com/show_bug.cgi?id=1234605#c3 --- Comment #3 from Ivan Ivanov <ivan.ivanov(a)suse.com> --- SLE15-SP5 will need fix too... -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1234605] Userspace crashes on parallels VM
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1234605 https://bugzilla.suse.com/show_bug.cgi?id=1234605#c2 Ivan Ivanov <ivan.ivanov(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|IN_PROGRESS |RESOLVED --- Comment #2 from Ivan Ivanov <ivan.ivanov(a)suse.com> --- Merged in SLE15-SP6 with eb067539dc2620b2ddcb2119576c06e4c0ec4fb3 Merged in SUSE-2025 with fc264097ad13ae2a5596102654cc8816a5c768df -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1234010] Unable to unlock multiple encrypted partitions with FIDO2 Key, Systemdboot+LUKS
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1234010 https://bugzilla.suse.com/show_bug.cgi?id=1234010#c3 Alberto Planas Dominguez <aplanas(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED --- Comment #3 from Alberto Planas Dominguez <aplanas(a)suse.com> --- Sorry for the delay. Reading your logs I am able to reproduce it: ``` Dec 01 18:25:45 localhost kernel: hid-generic 0003:26CE:01A2.0001: input,hidraw0: USB HID v1.10 Device [ASRock LED Controller] on usb-0000:02:00.0-8/input0 Dec 01 18:25:45 localhost kernel: hid-generic 0003:1050:0120.0002: hiddev96,hidraw1: USB HID v1.10 Device [Yubico Security Key by Yubico] on usb-0000:02:00.0-2.2/input0 Dec 01 18:25:45 localhost kernel: usb 1-2.4.1: new full-speed USB device number 7 using xhci_hcd Dec 01 18:25:45 localhost systemd-cryptsetup[790]: Failed to open FIDO2 device /dev/hidraw1: FIDO_ERR_RX Dec 01 18:25:45 localhost systemd-cryptsetup[790]: Token returned error during pre-flight: Input/output error Dec 01 18:25:45 localhost systemd-cryptsetup[790]: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/1b692ff9-23f5-4d84-86ee-51b3c3cb72c4. Dec 01 18:25:45 localhost systemd-cryptsetup[790]: Specified device /dev/hidraw1 is not a FIDO2 device. Dec 01 18:25:45 localhost systemd-cryptsetup[790]: Security token not present for unlocking volume Samsung SSD 990 PRO with Heatsink 1TB (cr_swap), please plug it in. Dec 01 18:25:45 localhost systemd-cryptsetup[790]: Specified device /dev/hidraw1 is not a FIDO2 device. Dec 01 18:25:45 localhost systemd-cryptsetup[789]: Asking FIDO2 token for authentication. Dec 01 18:25:45 localhost systemd-cryptsetup[789]: Please confirm presence on security token to unlock. ``` It is a race condition in systemd. Both cr_root and cr_swap are trying to access to the FIDO2 key, causing problems. I filled an issue upstream: https://github.com/systemd/systemd/issues/35671 We need to add somehow an ordering in the unlock -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1234513] New: VUL-0: : traefik: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1234513 Bug ID: 1234513 Summary: VUL-0: : traefik: golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other URL: https://smash.suse.de/issue/432234/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: alexandre.vicenzi(a)suse.com Reporter: gianluca.gabrielli(a)suse.com QA Contact: security-team(a)suse.de Blocks: 1234482 Target Milestone: --- Found By: --- Blocker: --- Applications and libraries which misuse the ServerConfig.PublicKeyCallback callback may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-45337 https://www.cve.org/CVERecord?id=CVE-2024-45337 https://github.com/golang/crypto/commit/b4f1988a35dee11ec3e05d6bf3e90b695fb… https://go.dev/cl/635315 https://go.dev/issue/70779 https://groups.google.com/g/golang-announce/c/-nPEi39gI4Q/m/cGVPJCqdAQAJ https://pkg.go.dev/vuln/GO-2024-3321 http://www.openwall.com/lists/oss-security/2024/12/11/2 https://bugzilla.redhat.com/show_bug.cgi?id=2331720 https://github.com/CVEProject/cvelistV5/blob/main//cves/2024/45xxx/CVE-2024… -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1233246] Random Soft Lockup on Lenovo Yoga Pro 7 14ASP9 with AMD GPU
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1233246 https://bugzilla.suse.com/show_bug.cgi?id=1233246#c5 --- Comment #5 from Zhang <2835365572zty(a)gmail.com> --- No, it didn't fix. It happens again. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1233016] memory buff/cache issue with qemu
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1233016 https://bugzilla.suse.com/show_bug.cgi?id=1233016#c26 --- Comment #26 from Jiri Slaby <jslaby(a)suse.com> --- (In reply to Krueger from comment #25) > Where can I register for api.opensuse.org? > I was asked for Username [api.opensuse.org] Sign Up at: https://build.opensuse.org/ -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1233016] New: memory buff/cache issue with qemu
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1233016 Bug ID: 1233016 Summary: memory buff/cache issue with qemu Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel:Storage Assignee: kernel-bugs(a)suse.de Reporter: itservice(a)knut-krueger.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- When a Windows VM is started, possibly also a Linux VM with high memory allocation, the buff/cache fills up instead of emptying if there is not enough free memory. In addition, the swap is filled more and more, the wait states increase. At some point, keyboard and mouse inputs are impossible. It is definitely not due to the VM, because if you boot with kernel 6.10.9-1-default ID=“opensuse-tumbleweed” ID_LIKE=“opensuse suse” VERSION_ID=“20241104” the memory allocation works perfectly. Here is the whole thread that helped troubleshooting with screenprints from TOP: https://forums.opensuse.org/t/kvm-partially-and-irregularly-freezes-the-win… -- You are receiving this mail because: You are on the CC list for the bug.

1 17

[Bug 1230118] [SELinux] Select SELinux as default MAC in enforcing mode in the tumbleweed installer
by bugzilla_noreply＠suse.com 18 Dec '24

18 Dec '24

https://bugzilla.suse.com/show_bug.cgi?id=1230118 Ricardo Branco <rbranco(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbranco(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0