Bug#954094: /bin/systemd: Running startx in X session switches to VC, input duplicated to X, login at getty exfiltrates creds

[Justus Winter]

Package: systemd
Version: 241-7~deb10u3
Severity: critical
File: /bin/systemd
Tags: security
Justification: root security hole

Dear Maintainer,

I was trying to spawn an Xephyr server using startx, but messed up the
arguments (I can reproduce it by simply running 'startx').  My X
session seemingly died, i.e. I was switched back to Linux' virtual
consoles.  I tried to switch back to X by cycling through all of the
VCs, but it didn't bring back the session, so I was convinced that it
had died.  I noticed that I could still see my graphical mouse
pointer, but was thinking nothing of it.

Convinced that my X session had died I logged in at a virtual console
to investigate and restart the display manager.  The login succeeded,
and I was able to restart the display manager.

To my surprise, I discovered that my login credentials were not only
sent to the getty, but also to the still running X session, where it
was sent to an instant messenger, and were exfiltrated to a third
party.  It doesn't help that getty interactions are quite distinct.

I expect that my keyboard inputs are never sent to both an X session
and a virtual console.

I can reliably reproduce it in a virtual machine with a fresh
installation.

Steps to reproduce:

 - Start slim, login as user, start Xmonad session
 - Start an xterm, run 'cat > x'
 - Start (Alt-p) startx
 - Watch your x session being replaced by an empty VC
 - Alt-F1, login as user
 - Run 'cat x':

     user at debian:~$ cat x
     user
     password
     cat x
     user at debian:~$

You can find a video of me reproducing it on my laptop here:

https://teythoon.avior.uberspace.de/tmp/linux-xorg-exfiltrates-credentials.x264.avi

(For dramatic effect, I exfiltrated to my desktop in the video).

I don't know if that matters, but:

# grep allowed_users /etc/X11/Xwrapper.config
allowed_users=anybody

I previously reported this to the security team, but they asked me to
refile it as a normal bug against systemd, because the fix likely
requires coordination between packages.

-- Package-specific info:

-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser          3.118
ii  libacl1          2.2.53-4
ii  libapparmor1     2.13.2-10
ii  libaudit1        1:2.8.4-3
ii  libblkid1        2.33.1-0.1
ii  libc6            2.28-10
ii  libcap2          1:2.25-2
ii  libcryptsetup12  2:2.1.0-5+deb10u2
ii  libgcrypt20      1.8.4-5
ii  libgnutls30      3.6.7-4+deb10u2
ii  libgpg-error0    1.35-1
ii  libidn11         1.33-2.2
ii  libip4tc0        1.8.2-4
ii  libkmod2         26-1
ii  liblz4-1         1.8.3-1
ii  liblzma5         5.2.4-1
ii  libmount1        2.33.1-0.1
ii  libpam0g         1.3.1-5
ii  libseccomp2      2.3.3-4
ii  libselinux1      2.8-1+b1
ii  libsystemd0      241-7~deb10u3
ii  mount            2.33.1-0.1
ii  util-linux       2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus            1.12.16-1
ii  libpam-systemd  241-7~deb10u3

Versions of packages systemd suggests:
ii  policykit-1        0.105-25
pn  systemd-container  <none>

Versions of packages systemd is related to:
pn  dracut           <none>
ii  initramfs-tools  0.133+deb10u1
ii  udev             241-7~deb10u3

-- no debconf information