Alerts This Week
Warning Icon 1 640
Alerts This Week
Warning Icon 1 640

Gentoo Linux GLSA-202402-02 Normal Severity: SDDM Privilege Escalation Risk

gentoo
Calendar Grey February 3, 2024
Dist Gentoo Esm H88
The Gentoo security advisory addresses a serious vulnerability in SDDM, urging users to review the issue to understand system security impacts and update accordingly to prevent exploitation.
A vulnerability has been discovered in SDDM which can lead to privilege escalation.

Summary

A vulnerability has been discovered in SDDM. Please review the CVE identifier referenced below for details.

Resolution

All SDDM users should upgrade to the latest version:
# emerge --sync # emerge --ask --oneshot --verbose ">=x11-misc/sddm-0.18.1-r6"

References

[ 1 ] CVE-2020-28049 https://nvd.nist.gov/vuln/detail/CVE-2020-28049

Availability

This GLSA and any updates to it are available for viewing at the Gentoo Security Website:
https://security.gentoo.org/glsa/202402-02
style>.gentoo_availability{display:block;}

Concerns

Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users' machines is of utmost importance to us. Any security concerns should be addressed to security@gentoo.org or alternatively, you may file a bug at https://bugs.gentoo.org.

Severity: Normal
Title: SDDM: Privilege Escalation
Date: February 03, 2024
Bugs: #753104
ID: 202402-02

Synopsis

A vulnerability has been discovered in SDDM which can lead to privilege escalation.

Background

SDDM is a modern display manager for X11 and Wayland sessions aiming to be fast, simple and beautiful. It uses modern technologies like QtQuick, which in turn gives the designer the ability to create smooth, animated user interfaces.

Get the latest News and Insights

Get the latest Linux and open source security news straight to your inbox.

Affected Packages

Package Vulnerable Unaffected ------------- ------------ ------------ x11-misc/sddm < 0.18.1-r6 >= 0.18.1-r6

Impact

SDDM passes the -auth and -displayfd command line arguments when starting the Xserver. It then waits for the display number to be received from the Xserver via the `displayfd`, before the Xauthority file specified via the `-auth` parameter is actually written. This results in a race condition, creating a time window in which no valid Xauthority file is existing while the Xserver is already running.
The X.Org server, when encountering a non-existing, empty or corrupt/incomplete Xauthority file, will grant any connecting client access to the Xorg display. A local unprivileged attacker can thus create an unauthorized connection to the Xserver and grab e.g. keyboard input events from other legitimate users accessing the Xserver.

Workaround

There is no known workaround at this time.

Your message here