When entering (correct) password, then waiting for timeout, password gets copied on CLI!

[mbiebl]

Forwarded from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093276

When, as a normal user, I call a command that requires root privileges on the command line, instead of getting rejected, I'm asked for root/admin password. I think the tool used to do that is polkit. That's why I post here.

When I enter my (correct) password, but then DO NOT validate it by hitting return, then let the login/polkit TIMEOUT trigger, then my actual password get copy-pasted on the command line!!!!

When I use "sudo" directly, there is no timeout, thus it does not happen.

Example:

[✘] user@localmachine:~$ service ollama stop
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====  ## <- I think it is polkit/pkexec that's called here?
Authentication is required to stop 'ollama.service'.
Authenticating as: USER,,, (user)
Password: Failed to stop ollama.service: Connection timed out       ## <- I just wait for timeout here
See system logs and 'systemctl status ollama.service' for details.
polkit-agent-helper-1: pam_authenticate failed: Authentication failure
[✘] user@localmachine:~$ MyPassw0rd!                                ## My password is pasted on the CLI!!!!

[smcv]

This is "typeahead". If you type text at a prompt, but the program that is doing the prompting exits before it receives anything from standard input (and if standard input is in line-buffered mode, then it won't receive any input until you press Return, which you didn't do), then the text you typed remains in some internal buffer and is made available to the next process that tries to read from the terminal - which, in this case, is the shell.

Mechanically this is quite similar to what happens if you:

• are in a shell
• run a command that will take some time, for example timeout 10s cat
• get impatient and start typing your next command before it has exited, for example echo $?
• when the slow command eventually exits, you expect echo $? to already be waiting at your next shell prompt

But obviously this is not what you want when the text being entered is a password.

Probably the component that is doing the prompting (it's not 100% clear to me whether this is systemctl, or polkit's temporary internal agent) should either:

1. after it has shown a prompt, refuse to exit until either input has been received or it has been killed by a signal, whichever comes first; or
2. explicitly flush the terminal buffer (possibly tcflush(STDIN_FILENO, TCIFLUSH) would do this?) before exiting

[jrybar-rh]

This is a known issue on which I spent some time investigating.

This is "typeahead". If you type text at a prompt, but the program that is doing the prompting exits before it receives anything from standard input (and if standard input is in line-buffered mode, then it won't receive any input until you press Return, which you didn't do), then the text you typed remains in some internal buffer and is made available to the next process that tries to read from the terminal - which, in this case, is the shell.

Exactly. The difference between sudo and pkttyagent (where the prompt happens) is that while sudo scans for every character (IIRC), pkttyagent uses PAM stack which asks for the entire stdin line.

Mechanically this is quite similar to what happens if you:

* are in a shell

* run a command that will take some time, for example `timeout 10s cat`

* get impatient and start typing your next command before it has exited, for example `echo $?`

* when the slow command eventually exits, you expect `echo $?` to already be waiting at your next shell prompt

But obviously this is not what you want when the text being entered is a password.

Probably the component that is doing the prompting (it's not 100% clear to me whether this is systemctl, or polkit's temporary internal agent) should either:

1. after it has shown a prompt, refuse to exit until either input has been received or it has been killed by a signal, whichever comes first; or

The problem is that polkit doesn't own the data until 'enter' is hit and when the timeout happens, pkttyagent is killed abruptly by a signal coming from PAM stack and then it's late. Maybe I could delete the line from a signal handler, but... vv

2. explicitly flush the terminal buffer (possibly `tcflush(STDIN_FILENO, TCIFLUSH)` would do this?) before exiting

... the characters are probably in the terminal emulator's buffer! I already tried to flush the STDIN, it doesn't work.

While having you all here, please let's discuss the next password-showing-related things somewhere else as mentioned in the README

[mbiebl]

Since the issue was already "out in the open" as per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093276 I didn't think it would make sense to pretend it was confidential at this point. Do you disagree?

[smcv]

Since the issue was already "out in the open" as per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093276 I didn't think it would make sense to pretend it was confidential at this point.

Yeah, that. If the original reporter had reported this privately to the Debian security team, rather than to the public bug tracker, then I expect it would also have been forwarded upstream privately... but that didn't happen, so the cat is already out of the bag.

[eslerm]

I verified this on Ubuntu. Ubuntu 22.04 (Jammy) is not affected. 24.04, 24.10, and devel are affected. Both Ubuntu 24.04 Desktop and Server are affected.

Any text not submitted will be returned--not just a correct password.

To test, I started a fresh VM and logged in as the default user in either a virtual console (Ubuntu Desktop) or SSHd in (Ubuntu Server), and ran systemctl restart avahi, typed something in, and waited.

On Ubuntu, the version of policykit-1 in 22.04 and 24.04 are respectively 0.105-33 and 124-2ubuntu1. I'm not sure how the prior number relates to upstream versioning.

[mbiebl]

I can confirm that 0.105-31+deb11u1 as shipped in Debian oldstable/bullseye does not exhibit this problem.

[eslerm]

The bug report on Ubuntu is https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/2095001

To check if this affects a non-Debian based system I setup Fedora Workstation 41 (GNOME) and could not reproduce the issue. This hints that Debian's version of polkit is the source of the issue.

My laptop running Ubuntu Server 24.04 and sway is not affected by this. I have polkitd installed, but not policykit-1 (nor gdm/gnome).

[smcv]

24.04, 24.10, and devel are affected

If I'm reading correctly, Ubuntu devel has polkitd (policykit-1) version 126-2, which doesn't apply any Debian/Ubuntu-specific patches any more; if that's the case then it seems unlikely that a Debian-specific patch to polkit is causing this. Could this be a difference in some lower-level component, like perhaps PAM?

pkttyagent uses PAM stack which asks for the entire stdin line

If pkttyagent uses PAM for prompting, could this be a behaviour difference between Fedora and Debian/Ubuntu PAM?

[mbiebl]

Upstream has contacted me privately (I hope it's ok to reveal that), saying that this is a known issue.
And afaik upstream is not using Debian, so I highly doubt it's a Debian specific issue.

EDIT: actually, @jrybar-rh already mentioned that this is a known issue in #545 (comment)

[mbiebl]

I just tested a F41 VM and could reproduce the problem there.

An interesting observation:
pkexec foo does not time out, systemctl stop foo does time out.