Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Server/Linux: Listen on abstract X UDS by default
Recent versions of Linux configure the primary X server to listen on both a pathname Unix domain socket (/tmp/.X11-unix/X$n, where $n is the X display number) and an abstract Unix domain socket (@/tmp/.X11-unix/X$n). Referring to this long thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/LDZNJJOQ5U74DRLBNSDOXJFPX5XIWCLT/ an issue exists with fixed-name abstract Unix domain sockets whereby an unprivileged user can create a dummy abstract UDS with a specific name and thus prevent an application that requires an abstract UDS with the same name from starting. However, in the case of X11, the use of a shared world-writable filesystem directory (/tmp/.X11-unix) for all pathname X11 Unix domain sockets already exposes the system to precisely this type of attack. That is a limitation of X11 that cannot be addressed within the scope of TurboVNC. (The same attack is possible with local X11 sessions.) In fact, I posit that it is safer for a TurboVNC session to claim the abstract UDS associated with its X display number. Otherwise a user could conceivably build a special version of Xvnc that ignores the X11 lock file, and they could hijack the X display of another user's TurboVNC session (that was started with '-nolisten local', which was the default) by starting their special version of Xvnc with '-listen local -nolisten unix', instructing Xvnc to listen on the same X display as the other user's TurboVNC session, and instructing Xvnc to listen on a currently unclaimed RFB port. This exploit works because modern Linux X11 applications prefer to communicate with the X server using the abstract UDS, if available, rather than the pathname UDS. The exploit described above is precisely what happened if a TurboVNC session was listening on Display :1 and a local session was started using GDM (if GDM was configured with WaylandEnable=false.) GDM ignored the presence of /tmp/.X1-lock and /tmp/.X11-unix/X1 and used Display :1 for the local session, thus stomping on the TurboVNC session's display. (Refer to: https://bugzilla.redhat.com/show_bug.cgi?id=1673793.) If the TurboVNC session listens on the abstract UDS as well as the pathname UDS associated with Display :1, then GDM will choose Display :2 for the local session. Should this change prove problematic, it can easily be reverted on a system-wide or per-user basis by setting $serverArgs = "-nolisten local"; in turbovncserver.conf. This commit also documents bc73242.
- Loading branch information