Activity log for bug #1803993

Date Who What changed Old value New value Message
2018-11-19 13:46:11 Thomas Carlisle bug added bug
2018-11-20 03:17:47 Seth Arnold information type Private Security Public Security
2018-11-20 03:17:49 Seth Arnold bug added subscriber Ubuntu Bugs
2018-11-20 03:32:06 Daniel van Vugt summary GDM is Exploitable as a Password Collector Password appears on the VT1 screen
2018-11-20 03:33:40 Daniel van Vugt gdm3 (Ubuntu): status New Incomplete
2018-11-20 03:34:34 Daniel van Vugt bug task added plymouth (Ubuntu)
2018-11-20 03:34:38 Daniel van Vugt plymouth (Ubuntu): status New Incomplete
2018-11-20 18:57:56 Marian Rainer-Harbach bug added subscriber Marian Rainer-Harbach
2018-11-21 21:22:09 Seth Arnold gdm3 (Ubuntu): status Incomplete New
2018-11-21 21:22:12 Seth Arnold plymouth (Ubuntu): status Incomplete New
2018-12-18 02:49:33 Launchpad Janitor gdm3 (Ubuntu): status New Confirmed
2018-12-18 02:49:33 Launchpad Janitor plymouth (Ubuntu): status New Confirmed
2018-12-18 02:51:07 Steven Schram bug added subscriber Steven Schram
2019-01-07 15:47:07 Gaussian bug added subscriber Gaussian
2019-01-31 13:35:20 Francis Ginther tags amd64 apport-bug bionic third-party-packages amd64 apport-bug bionic id-5c51b3a3cb40343530f1abbd third-party-packages
2019-02-04 15:53:24 Jeremy Soller bug added subscriber Jeremy Soller
2019-02-18 10:11:26 Daniel van Vugt description This was found when an administrative error made /home directory inaccessible. Any users that tried to login after that, were not able to (which is expected) but their password appears on the VT1 screen. Under normal circumstances, VT1 is not visible. But once the system was sent into this compromised mode, one can press ctrl+alt+F1 and then ctrl+alt+F2 and get a momentary glance at VT1. One can keep toggling between these key combinations in order to make out the password(s) on VT1. As a further test, I wanted to see if a non-super user could cause this condition, and it is in fact possible. As a regular user, I made their own home directory not writable and then removed ~/.config and logged out. Then logged in as that user again, and although that user can't login the system does go into that mode where passwords appear on VT1 and are viewable with the key combinations mentioned herein. Further, any other users that login will see no problem, but when they logon their passwords also appear on VT1 and are viewable. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.3 Uname: Linux 4.19.2-041902-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Nov 19 08:32:59 2018 InstallationDate: Installed on 2018-08-25 (85 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR=<set> LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) (continued from bug 1767918) This was found when an administrative error made /home directory inaccessible. Any users that tried to login after that, were not able to (which is expected) but their password appears on the VT1 screen. Under normal circumstances, VT1 is not visible. But once the system was sent into this compromised mode, one can press ctrl+alt+F1 and then ctrl+alt+F2 and get a momentary glance at VT1. One can keep toggling between these key combinations in order to make out the password(s) on VT1. As a further test, I wanted to see if a non-super user could cause this condition, and it is in fact possible. As a regular user, I made their own home directory not writable and then removed ~/.config and logged out. Then logged in as that user again, and although that user can't login the system does go into that mode where passwords appear on VT1 and are viewable with the key combinations mentioned herein. Further, any other users that login will see no problem, but when they logon their passwords also appear on VT1 and are viewable. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.3 Uname: Linux 4.19.2-041902-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Nov 19 08:32:59 2018 InstallationDate: Installed on 2018-08-25 (85 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron:  TERM=xterm-256color  PATH=(custom, no user)  XDG_RUNTIME_DIR=<set>  LANG=en_US.UTF-8  SHELL=/bin/bash SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install)
2019-03-21 06:16:58 Norbert bug added subscriber Norbert
2019-04-17 01:59:02 Daniel van Vugt gdm3 (Ubuntu): importance Undecided High
2019-04-17 01:59:05 Daniel van Vugt plymouth (Ubuntu): importance Undecided High
2019-04-17 14:44:54 Brian Murray bug added subscriber Brian Murray
2019-04-24 14:06:20 Balint Reczey bug task added systemd (Ubuntu)
2019-04-24 15:47:48 Balint Reczey systemd (Ubuntu): importance Undecided High
2019-04-24 15:47:51 Balint Reczey systemd (Ubuntu): assignee Balint Reczey (rbalint)
2019-04-24 16:00:24 Bryan Quigley bug added subscriber Bryan Quigley
2019-04-24 17:53:51 Balint Reczey systemd (Ubuntu): status New Confirmed
2019-04-24 17:53:57 Balint Reczey systemd (Ubuntu): status Confirmed In Progress
2019-04-24 21:35:58 Balint Reczey gdm3 (Ubuntu): status Confirmed Invalid
2019-04-24 21:36:03 Balint Reczey plymouth (Ubuntu): status Confirmed Invalid
2019-04-24 21:46:55 Steven Schram removed subscriber Steven Schram
2019-04-25 13:46:55 Dan Streetman bug added subscriber Dan Streetman
2019-05-17 15:02:32 Balint Reczey description (continued from bug 1767918) This was found when an administrative error made /home directory inaccessible. Any users that tried to login after that, were not able to (which is expected) but their password appears on the VT1 screen. Under normal circumstances, VT1 is not visible. But once the system was sent into this compromised mode, one can press ctrl+alt+F1 and then ctrl+alt+F2 and get a momentary glance at VT1. One can keep toggling between these key combinations in order to make out the password(s) on VT1. As a further test, I wanted to see if a non-super user could cause this condition, and it is in fact possible. As a regular user, I made their own home directory not writable and then removed ~/.config and logged out. Then logged in as that user again, and although that user can't login the system does go into that mode where passwords appear on VT1 and are viewable with the key combinations mentioned herein. Further, any other users that login will see no problem, but when they logon their passwords also appear on VT1 and are viewable. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.3 Uname: Linux 4.19.2-041902-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Nov 19 08:32:59 2018 InstallationDate: Installed on 2018-08-25 (85 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron:  TERM=xterm-256color  PATH=(custom, no user)  XDG_RUNTIME_DIR=<set>  LANG=en_US.UTF-8  SHELL=/bin/bash SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) [Impact] * The keyboard on the graphical login screen started on VT1 may stop working and or keypresses including passwords are leaked to the terminal console running 'behind' the graphical login screen or environment. [Test Case] * Reboot after installing the fixed systemd package. * Install sysdig * Start sysdig on a remote connection or on a terminal console: $ sudo sysdig evt.type=ioctl | grep request=4B4 * While sysdig is running log in and out 3 times in GDM and press a few keys in the graphical session to see if keyboard still works * Log in and out on an other terminal console, too, running a few commands while being logged in to ensure that keyboard is working. * Observe that on terminal consoles the monitored keyboard setter ioctl is called with argument=3, but where the graphical screen is active only argument=4 is used, unlike with the buggy version observed in https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1803993/comments/14 [Regression Potential] * The fix checks the current keyboard mode of the VT and allows only safe mode switches. The potential regression could be not allowing a valid mode switch keeping a keyboard in a non-operational mode. Testing covers that by typing the keyboard. (continued from bug 1767918) This was found when an administrative error made /home directory inaccessible. Any users that tried to login after that, were not able to (which is expected) but their password appears on the VT1 screen. Under normal circumstances, VT1 is not visible. But once the system was sent into this compromised mode, one can press ctrl+alt+F1 and then ctrl+alt+F2 and get a momentary glance at VT1. One can keep toggling between these key combinations in order to make out the password(s) on VT1. As a further test, I wanted to see if a non-super user could cause this condition, and it is in fact possible. As a regular user, I made their own home directory not writable and then removed ~/.config and logged out. Then logged in as that user again, and although that user can't login the system does go into that mode where passwords appear on VT1 and are viewable with the key combinations mentioned herein. Further, any other users that login will see no problem, but when they logon their passwords also appear on VT1 and are viewable. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.3 Uname: Linux 4.19.2-041902-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Nov 19 08:32:59 2018 InstallationDate: Installed on 2018-08-25 (85 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron:  TERM=xterm-256color  PATH=(custom, no user)  XDG_RUNTIME_DIR=<set>  LANG=en_US.UTF-8  SHELL=/bin/bash SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install)
2019-05-17 18:40:54 Seth Arnold cve linked 2018-20839
2019-06-05 01:33:15 Launchpad Janitor systemd (Ubuntu): status In Progress Fix Released
2019-06-05 10:16:11 Dimitri John Ledkov systemd (Ubuntu): status Fix Released Confirmed
2019-09-05 12:16:19 Michael Biebl bug watch added https://gitlab.freedesktop.org/xorg/xserver/issues/857
2020-04-14 09:37:25 Dan Streetman tags amd64 apport-bug bionic id-5c51b3a3cb40343530f1abbd third-party-packages amd64 apport-bug bionic ddstreet id-5c51b3a3cb40343530f1abbd third-party-packages
2020-04-14 10:24:02 Balint Reczey systemd (Ubuntu): assignee Balint Reczey (rbalint)
2020-06-19 15:31:27 Bryan Quigley removed subscriber Bryan Quigley
2020-07-24 19:06:39 Dan Streetman tags amd64 apport-bug bionic ddstreet id-5c51b3a3cb40343530f1abbd third-party-packages amd64 apport-bug bionic id-5c51b3a3cb40343530f1abbd third-party-packages
2021-04-12 16:49:04 Dan Streetman systemd (Ubuntu): status Confirmed Invalid
2021-04-12 16:49:07 Dan Streetman plymouth (Ubuntu): status Invalid Fix Released