Ubuntu
gdm3 package

Password appears on the VT1 screen

Bug #1803993 reported by Thomas Carlisle
314
This bug affects 7 people
Affects Status Importance Assigned to Milestone
gdm3 (Ubuntu)
Invalid
High
Unassigned
plymouth (Ubuntu)
Fix Released
High
Unassigned
systemd (Ubuntu)
Invalid
High
Unassigned

Bug Description

[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)

See original description

CVE References

Revision history for this message
Thomas Carlisle (tcarlisle2012) wrote :
Revision history for this message
Seth Arnold (seth-arnold) wrote :

Hello Thomas, can you please report back what version of plymouth you have installed?

dpkg -l plymouth | grep ^ii

Thanks

information type: Private Security → Public Security
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

^^^
That is probably just to verify this really isn't a duplicate of bug 1767918, and that you have the fix for bug 1767918 already.

summary: - GDM is Exploitable as a Password Collector
+ Password appears on the VT1 screen
Changed in gdm3 (Ubuntu):
status: New → Incomplete
Changed in plymouth (Ubuntu):
status: New → Incomplete
Revision history for this message
Thomas Carlisle (tcarlisle2012) wrote : Re: [Bug 1803993] Re: GDM is Exploitable as a Password Collector

Hi Seth,

It is: 0.9.3-1ubunt

On Mon, Nov 19, 2018 at 10:30 PM Seth Arnold <email address hidden>
wrote:

> Hello Thomas, can you please report back what version of plymouth you
> have installed?
>
> dpkg -l plymouth | grep ^ii
>
> Thanks
>
> ** Information type changed from Private Security to Public Security
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1803993
>
> Title:
> GDM is Exploitable as a Password Collector
>
> Status in gdm3 package in Ubuntu:
> New
>
> Bug 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)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1803993/+subscriptions
>

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Hello Thomas, sadly you only got half of the version number. Can you please paste in the full version number?

Thanks

Revision history for this message
Thomas Carlisle (tcarlisle2012) wrote : Re: [Bug 1803993] Re: Password appears on the VT1 screen

HI Seth,

Sorry. It is plymouth 0.9.3ubuntu7.18.04.1 amd64

On Tue, Nov 20, 2018 at 5:35 PM Seth Arnold <email address hidden>
wrote:

> Hello Thomas, sadly you only got half of the version number. Can you
> please paste in the full version number?
>
> Thanks
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1803993
>
> Title:
> Password appears on the VT1 screen
>
> Status in gdm3 package in Ubuntu:
> Incomplete
> Status in plymouth package in Ubuntu:
> Incomplete
>
> Bug 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)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1803993/+subscriptions
>

Seth Arnold (seth-arnold)
Changed in gdm3 (Ubuntu):
status: Incomplete → New
Changed in plymouth (Ubuntu):
status: Incomplete → New
Revision history for this message
Seth Arnold (seth-arnold) wrote :

Thanks Thomas

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gdm3 (Ubuntu):
status: New → Confirmed
Changed in plymouth (Ubuntu):
status: New → Confirmed
Revision history for this message
Balint Reczey (rbalint) wrote :

It seems I can reproduce the issue in qemu and look at vt1 by stopping gdm3, since the switch to vt2 does not show vt1 even for a moment.

Francis Ginther (fginther)
tags: added: id-5c51b3a3cb40343530f1abbd
Daniel van Vugt (vanvugt)
description: updated
Revision history for this message
Norbert (nrbrtx) wrote :

Confirmed by https://askubuntu.com/q/1127408/66509

Revision history for this message
Robert Anderson (rwa-l) wrote :

I'm pretty sure I just encountered this bug, although all I did was issue a shutdown, and very briefly I was able to see several plaintext passwords that had been used to log in across several user accounts. I am on Ubuntu 18.04.2 LTS.

This was a shock for reasons which should be obvious.

Daniel van Vugt (vanvugt)
Changed in gdm3 (Ubuntu):
importance: Undecided → High
Changed in plymouth (Ubuntu):
importance: Undecided → High
Revision history for this message
Brian Murray (brian-murray) wrote :

@Robert Anderson - could you please report a new bug using ubuntu-bug plymouth? This will gather information from the system in question that will help us investigate the matter. Thanks in advance!

Revision history for this message
Balint Reczey (rbalint) wrote :

It looks like systemd is changing the mode (see argument=3) on VT1 on logouts.

#define K_RAW 0x00
#define K_XLATE 0x01
#define K_MEDIUMRAW 0x02
#define K_UNICODE 0x04
#define K_OFF 0x04
#define KDGKBMODE 0x4B44 /* gets current keyboard mode */
#define KDSKBMODE 0x4B45 /* sets current keyboard mode */

test@test-Standard-PC-i440FX-PIIX-1996:~$ sudo sysdig evt.type=ioctl | grep request=4B45
[sudo] password for test:
5657343 15:21:51.819076315 1 Xorg (1069) > ioctl fd=11(<f>/dev/tty1) request=4B45 argument=4
5657453 15:21:51.820019063 0 systemd-logind (575) > ioctl fd=22(<f>/dev/tty1) request=4B45 argument=3
5753055 15:21:52.771635876 0 systemd-logind (575) > ioctl fd=21(<f>/dev/tty1) request=4B45 argument=4
20723813 15:49:41.368621972 1 systemd (23717) > ioctl fd=3(<f>/dev/tty2) request=4B45 argument=3
22605710 15:53:04.107253025 1 systemd-logind (575) > ioctl fd=23(<f>/dev/tty3) request=4B45 argument=4
22612602 15:53:04.142057934 1 Xorg (24089) > ioctl fd=11(<f>/dev/tty3) request=4B45 argument=4
24077108 15:53:28.705600119 0 Xorg (24089) > ioctl fd=11(<f>/dev/tty3) request=4B45 argument=4
24077278 15:53:28.706353493 1 systemd-logind (575) > ioctl fd=24(<f>/dev/tty3) request=4B45 argument=3
24626343 15:53:58.336589416 0 systemd-logind (575) > ioctl fd=22(<f>/dev/tty1) request=4B45 argument=3
24804326 15:53:59.385872243 0 systemd-logind (575) > ioctl fd=21(<f>/dev/tty1) request=4B45 argument=4
25515114 15:54:12.915072995 1 systemd-logind (575) > ioctl fd=23(<f>/dev/tty3) request=4B45 argument=4
25520504 15:54:12.929480424 1 Xorg (25112) > ioctl fd=11(<f>/dev/tty3) request=4B45 argument=4
26921037 15:54:46.872029874 1 Xorg (25112) > ioctl fd=11(<f>/dev/tty3) request=4B45 argument=4
26921239 15:54:46.872654795 1 systemd-logind (575) > ioctl fd=24(<f>/dev/tty3) request=4B45 argument=3
27104852 15:54:53.870639078 1 systemd-logind (575) > ioctl fd=23(<f>/dev/tty3) request=4B45 argument=4
27112208 15:54:53.894217722 1 Xorg (25697) > ioctl fd=11(<f>/dev/tty3) request=4B45 argument=4
28677455 15:55:44.581119464 0 Xorg (25697) > ioctl fd=11(<f>/dev/tty3) request=4B45 argument=4
28678288 15:55:44.592966138 1 systemd-logind (575) > ioctl fd=24(<f>/dev/tty3) request=4B45 argument=3

Balint Reczey (rbalint)
Changed in systemd (Ubuntu):
importance: Undecided → High
assignee: nobody → Balint Reczey (rbalint)
Revision history for this message
Balint Reczey (rbalint) wrote :

Forwarded proposed fix to systemd upstream: https://github.com/systemd/systemd/pull/12378

Changed in systemd (Ubuntu):
status: New → Confirmed
status: Confirmed → In Progress
Balint Reczey (rbalint)
Changed in gdm3 (Ubuntu):
status: Confirmed → Invalid
Changed in plymouth (Ubuntu):
status: Confirmed → Invalid
Balint Reczey (rbalint)
description: updated
Revision history for this message
Seth Arnold (seth-arnold) wrote :

Use CVE-2018-20839.

Thanks

Revision history for this message
Dan Streetman (ddstreet) wrote :

This may have caused a regression upstream, see
https://github.com/systemd/systemd/pull/12378#issuecomment-493776598

Revision history for this message
Dan Streetman (ddstreet) wrote :

@rbalint, this is still in eoan-proposed, can you get it pushed out to eoan-updates (or revert it)?

Revision history for this message
Dan Streetman (ddstreet) wrote :

> can you get it pushed out to eoan-updates (or revert it)?

sorry i meant eoan-release

also, see discussion in #ubuntu-devel, I'll revert this patch in my upload to eoan, so that the regression can be figured out.

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (3.5 KiB)

This bug was fixed in the package systemd - 240-6ubuntu9

---------------
systemd (240-6ubuntu9) eoan; urgency=medium

  * Fix typpo in storage test.
    File: debian/tests/storage
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=f28aa5fe4ab175b99b6ea702559c59ca473b4ca8

  * Fix bashism
    File: debian/extra/dhclient-enter-resolved-hook
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=0725c1169ddde4f41cacba7af3e546704e2206be

systemd (240-6ubuntu8) eoan; urgency=medium

  * Only restart resolved on changes in dhclient enter hook.
    This prevents spurious restarts of resolved on rebounds when
    the addresses did not change. (LP: #1805183)
    Author: Julian Andres Klode
    File: debian/extra/dhclient-enter-resolved-hook
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=258893bae8cbb12670e4807636fe8f7e9fb5407a

  * Wait for cryptsetup unit to start, before stopping.
    Patch from cascardo. Plus small refactor for readability. (LP: #1814373)
    File: debian/tests/storage
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b65aa350be7e61c65927fbc0921a750fcfaa51cd

  * Wait for systemctl is-system-running state.
    File: debian/tests/boot-smoke
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=776998f1f55c445b6e385cab69a4219c42d00838

systemd (240-6ubuntu7) eoan; urgency=medium

  * Revert "Add check to switch VTs only between K_XLATE or K_UNICODE"
    This reverts commit 60407728a1a453104e3975ecfdf25a254dd7cc44.
    Files:
    - debian/patches/Add-check-to-switch-VTs-only-between-K_XLATE-or-K_UNICODE.patch
    - debian/patches/Move-verify_vc_kbmode-to-terminal-util.c-as-vt_verify_kbm.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=18029ab5ff436bfb3b401f24cd1e3a4cf2a1579c

  * Cherrypick missing systemd-stable patches to unbreak wireguard peer endpoints.
    Signed-off-by: Dimitri John Ledkov <email address hidden> (LP: #1825378)
    Author: Dan Streetman
    Files:
    - debian/patches/network-wireguard-fixes-sending-wireguard-peer-setti.patch
    - debian/patches/network-wireguard-use-sd_netlink_message_append_sock.patch
    - debian/patches/sd-netlink-introduce-sd_netlink_message_append_socka.patch
    - debian/patches/test-network-add-more-checks-in-NetworkdNetDevTests..patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=4046f515e40c4dc80d18d2303466737f1f451f11

  * Remove expected failure from passing test.
    Signed-off-by: Dimitri John Ledkov <email address hidden> (LP: #1829450)
    Author: Dan Streetman
    File: debian/tests/systemd-fsckd
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c43b12037d08555dc1d26593307726d7c7992df0

  * Fix false negative checking for running jobs after boot.
    Signed-off-by: Dimitri John Ledkov <email address hidden> (LP: #1825997)
    Author: Dan Streetman
    File: debian/tests/boot-smoke
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=aeb01631efbaf3fe851dee15d496e0b66b5c347f

  * Cherrypick ask-password: prevent buffer ...

Read more...

Changed in systemd (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

This is still not fixed.

Changed in systemd (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Michael Biebl (mbiebl) wrote :

Looking at the discussion at https://gitlab.freedesktop.org/xorg/xserver/issues/857#note_201402 this might be a bug in plymouth which is supposedly fixed in plymouth 0.9.4.

Could users who can reliably reproduce the issue post if they have plymouth installed and if so, which version?

Revision history for this message
Michael Biebl (mbiebl) wrote :

@rbalint if you can reliably reproduce the issue, it would probably be a good idea if you follow up on that upstream bug tracker

Revision history for this message
Dan Streetman (ddstreet) wrote :

> Looking at the discussion at https://gitlab.freedesktop.org/xorg/xserver/issues/857#note_201402 this might be a bug in plymouth which is supposedly fixed in plymouth 0.9.4.

I noticed that, however that points to:
https://gitlab.freedesktop.org/plymouth/plymouth/commit/28ee4012c94b4045b97e5a2a66f66b7688b2dff3

which was added to plymouth in the bug preceeding this one, bug 1767918
https://launchpad.net/ubuntu/+source/plymouth/0.9.3-1ubuntu7.18.04.1

so, that specific patch doesn't seem to fix it, or at least not entirely...

Revision history for this message
Dan Streetman (ddstreet) wrote :

added info from previous comment to the upstream freedesktop bug.

Dan Streetman (ddstreet)
tags: added: ddstreet
Balint Reczey (rbalint)
Changed in systemd (Ubuntu):
assignee: Balint Reczey (rbalint) → nobody
Dan Streetman (ddstreet)
tags: removed: ddstreet
Revision history for this message
Dan Streetman (ddstreet) wrote :

As suggested in the freedesktop bug, this probably was fixed with the patch added for bug 1817738 which is this commit:
https://gitlab.freedesktop.org/plymouth/plymouth/-/commit/85d843af843589ce8538a59e5cb665b8253e380d

I haven't been able to reproduce this myself yet (when using the plymouth version previous to that fix), but I'll try a few more times next week.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Interesting. Though Plymouth probably shouldn't be running at all by the time you type a password into the login screen. If it's not running then that's probably not the cause.

Revision history for this message
Dan Streetman (ddstreet) wrote :

Unfortunately I can't reproduce this bug, even with the 0.9.3-1ubuntu7.18.04.1 version of plymouth installed, so I can't say for sure that it's fixed with plymouth 0.9.3-1ubuntu7.18.04.2.

Also note that the [test case] in the description is wrong, that would be correct with the systemd change made earlier, but that change was reverted upstream and in ubuntu, so the test case steps aren't an accurate indication that the bug is fixed or not.

Anyone on this bug able to reproduce the main problem, of key output (e.g. passwords) being printed on the console and visible between login sessions, and/or during shutdown? If not, I think we should consider this bug fixed.

Changed in systemd (Ubuntu):
status: Confirmed → Invalid
Changed in plymouth (Ubuntu):
status: Invalid → Fix Released
Revision history for this message
Dan Streetman (ddstreet) wrote :

I'm marking this invalid for systemd (the patch there was reverted) and fix released for plymouth, with the assumption this was fixed with the patch for bug 1817738.

If anyone is able to reproduce the problem please add a comment.

To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.