Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords
46 points by runxiyu
46 points by runxiyu
I’m fairly sure this actually fixes another security problem. Vanilla sudo is reading the password using Line buffering. So if you type your password and don’t press enter to submit it and then wait long enough, or something else kills the sudo process, your password will end up being echoed to the underlying shell in the clear.
You see the same behaviour in systemd’s password reading, which I think is polkit. Can’t remember if su suffers it as well.
Wow... This is obviously a far more substantial issue than knowing a password length. Just underlines how silly and theatrical the security debate on this really is.
Interestingly sudo-rs did have a conceptually similar CVE:
If a user begins entering a password but does not press return for an extended period, a password timeout may occur. When this happens, the keystrokes that were entered are echoed back to the console.
Interesting that they actually got a CVE for that. I’m fairly sure polkit and OG Sudo rejected it.
I've heard that this is actually intentional behavior: Without it, running sudo over SSH would leak your keystroke timings because a packet would be sent immediately after each key press.
If you password is a series of random words, that might be enough information to figure out what it is... although modern SSH adds random delays and sends identical, but empty "chaff" packets to prevent this attack.
Intuitively it feels like, for an over-the-shoulder attack, it would be much more effective to look at the keyboard rather than at the screen.
From the article:
[...] First, the security benefit of hiding password length is negligible in practice — anyone close enough to count asterisks on a screen is close enough to hear or watch your keystrokes directly. Second, and more pointedly, most users’ sudo password is the same as their login password — one that already appears as visible placeholder dots on the graphical login screen. Hiding asterisks in the terminal while showing them at login is, in the developers’ estimation, security theatre. [...]
Counter argument: Screen sharing exists and is part of many people's workflow. I often use sudo while sharing my screen in a video call, while I never encounter the login screen while in a video call.
Well, Wayland makes it near impossible to screen share, so I guess Canonical is compensating for revealing the password length.
It's not 2019 anymore
I wish it was as simple as looking at the calendar. I switched from i3 to sway earlier this year and spent several hours in multiple debugging sessions trying to get Zoom to share my screen. Trawling through old Reddit posts and a lot of dead links I learned about "portals"... which seem to be only partly implemented and are definitely underdocumented. Piecing together the right portals for the right protocols is left as an exercise for the reader. Seems to fall into a gap where each of the main groups views screen sharing as outside their core scope. Users get left to navigate it.
Before you point the noob-finger at me, you should know that I've been a Linux user since before distros and was comfortable building x386 (before X.org). There's a real gap in end-user documentation for Wayland.
It's actually pretty bad. One friend of mine knows how to nixify everything but couldn't get screensharing to run on discord. I failed to get a user friendly remote-desktop app stable on a bog standard Ubuntu, it worked at first but simply stopped any remote input after a couple days (you will regret that when it's your family trying to get help). Apparently there is only teamviewer for this - nothing else supports the fragmented ways of doing remote-control in wayland. I remember zoom crashing for me in 2023 when sharing screens on wayland. These days it's MacOS or Windows, I don't have time to fiddle around with my OS when also trying to write FOSS.
Counter counter argument, if you have a sufficiently long enough password it doesn't really matter all that much. One would also hope that password authentication for ssh has been turned off. So even if the person you are showing it to can guess the password based on the amount of characters they'd still also need to have physical access to your machine at other times. At which point they surely have been around to hear you type it as well.
I don't disagree with you about the password length. Keystroke timing is probably a much more relevant information vector. (See @runxiyu's comment). Apart from that: People seeing that someone has a short password can give them ideas.
Regarding password authentication for ssh: Password authentication for ssh is enabled by default. So, I'd argue in most cases physical access would not be necessary.
Tbh, I don't think that enabling pwfeedback by default is necessarily bad. It's a tradeoff between usability (visual feedback) and security. I don't have a strong opinion either way. Maybe obscuring keystroke timing (á la SSH) would be a good idea though.
Could be an interesting topic, but the framing that Ubuntu is ending 46 years of something is really messed up on a few levels. Ubuntu is, um, 22 years old this year?
The sudo-rs project has been around, and packaged for various distributions, for a number of years. But this seems to give all the credit to Ubuntu, which kind of smells to me. I wouldn't be surprised to learn Ubuntu isn't the first distribution to default to sudo-rs, but I'll grant it's the first major one to do so. However, it's not like this "ends" use of regular sudo by any stretch...
All that aside, Ubuntu 26.04 will be an interesting update when it lands; the switch to uutils and sudo-rs is a big step. Seems like a lot of work has gone into trying to find and squash bugs in uutils where it's not compatible with GNU utils, but the real test is going to be when large numbers of people and organizations start deploying 26.04 in production. I'm curious to see whether there are just a few growing pains or if anybody will hit major problems.
I feel that the framing is about the same level as saying that forty-something Odacer ended the thousand year rule of Rome. After all, Constantinople kept the Eastern empire going for another thousand years. Also, Odacer couldn't depose Romulus Augustus without the assistance of centuries of internal mismanagement within the empire. However, when you need a quick answer for when Rome fell, it's gonna be Odacer.
Reminder: you can entirely negate the entropy leak represented by knowing your password's length by... making your password one character longer.
From HN,
A few years ago, 0 made the following point in regards to password input feedback:
For a time, there was rich pickings in applications that accepted passwords in unbuffered mode. Many of them doing it so that they could echo "*" symbols, character by character, as the user typed. That simple feature looks cool, and does give the user feedback ... but would leak the keystroke rate, which is the last thing you want on password entry.
This was in response to keystroke timing defense on SSH. Does this feature still come with the risk of leaking keystroke timing to an attacker with recent OpenSSH/Dropbear versions? If so, it might be wise to keep it disabled on servers.
I think in OpenSSH this was mostly fixed with ObscureKeystrokeTiming which is enabled by default:
Specifies whether ssh(1) should try to obscure inter-keystroke timings from passive observers of network traffic. If enabled, then for interactive sessions, ssh(1) will send keystrokes at fixed intervals of a few tens of milliseconds and will send fake keystroke packets for some time after typing ceases. The argument to this keyword must be yes, no or an interval specifier of the form interval:milliseconds (e.g. interval:80 for 80 milliseconds). The default is to obscure keystrokes using a 20ms packet interval. Note that smaller intervals will result in higher fake keystroke packet rates.
Although that's on the client-side, if the server responds with a "*" symbol for each keystroke it might be possible to reconstruct password length from network traffic.
Last I checked, server responses are sent and delayed immediately with no obfuscation, so this could indeed be the case.
The first distro I saw that modified the sudo prefs to do this was Zorin, after which I started doing it on my Macs too. It’s been a few years, too.
Using a (tele-)typewriter without line buffering, if you misspell a character, and then retype it correctly, would the asterisk be written twice on the same position on the continuous stationery? If so, that means that not only are you revealing the length, you are also revealing the approximate location of characters thought to be mistyped, since they will have the ink doubly applied. They will appear darker.
I don’t think Ubuntu should be setting its defaults to cater to people who are using a teletypewriter in 2026. If you are doing that, it’s definitely a novelty thing, and I’m sure you can figure out how to turn this off if it’s a concern.
One angle I haven't seen raised: masking might actually give a false sense of security. The correct practice when someone could be watching is to not enter your password at all, and visible masking may subtly signal that doing so is fine. Friction has value sometimes. I'm not fully sold on this view, but it feels like the stronger argument for the old behavior than “password length leakage.”
In that case the correct thing to do would to display the password in plain text. This makes it obvious to the user that anyone could potentially "see" (by whatever means) their password if there in person.