"a local privilege escalation has been discovered in the sddm display
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.
A simple reproducer works like this:
# run this from an unpriliged account before sddm is started to exploit
# the race condition and kill the X server
inotifywait /tmp/.X11-unix; while ! xkill; do :; done
The security issue was discovered by our SUSE sddm package maintainer
Fabian Vogt. The issue is included in sddm since version 0.12.0 and
was recently fixed in a new upstream release 0.19.0. The upstream commit
fixing this issue is found in . The SUSE bugzilla bug tracking this
issue is found in ."
Please apply or bump to 0.19.0.
We should perhaps wait with a bump to 0.19.0 until upstream fixed the following regression:
Created attachment 671800 [details, diff]
While toying with 0.19.0 I had to "fix" the pam-1.4 patch
Yup, we don't need yet another race condition in SDDM. A big update on the ebuild will be incoming soon, anyway, perhaps I should just make a PR with 0.19.0 while we wait for them to fix their stuff.
*** Bug 790713 has been marked as a duplicate of this bug. ***
Ping: any news?
Package list is empty or all packages have requested keywords.