xwayland: Removal of abstract sockets possibly harmful
Affected version
- mutter from git master
- Wayland
Bug summary
This is a follow up of the discussions in !1669 (comment 1010796)
Basically, commit e2123768 removed support for abstract sockets in mutter xwayland code to solve mutter issue #1289 (closed) during the 3.38 development cycle.
However that raised some other issues like #1454 (closed) or #1468 so commit e2123768 was reverted in GNOME 3.38.1 with !1508 (merged).
Yet the current code in master still has support for abstract sockets removed.
That will likely reintroduce the issues raised in #1454 (closed) or #1468 once GNOME 40 is out, but this also has some other (more serious, imho) implications.
First of all, mutter might guess the display number wrong as in #1604 (closed) because some other Xserver would be listening on abstract sockets while not having a lock file.
But more importantly, I reckon that opens a security risk because X11 clients are still trying abstract sockets first.
Someone could write a fake X11 server which would listen to the abstract socket (that mutter left out) for the given display, and forward that to the regular socket (that mutter listen to).
X11 clients would happily try the abstract socket first, get the connection and start sending input events (among others), the fake xserver would just need to log those and forward everything to the regular socket. Doing so, the display number remains the same, and the X11 clients (or even user) has no easy way to tell there is some rogue fake xserver in-between the client and Xwayland.
Steps to reproduce
- Run gnome-terminal, and launch
xvfb-run -d xclock
- Launch
xterm
from gnome-shell
What happened
xterm
does not show up on screen because it's running in Xvfb
.
What did you expect to happen
xterm
shows up on screen.