Sometimes it occurs to me, when doing something like a brew install, or really anything on a CLI (though I suppose this is also true of GUIs to a marginally lesser extent) that prompts me for a password - that really no effort is made to authenticate that it is the OS that has control of stdin.

It seems, to me at least, that one could write a program that would seem reasonable to give root access, though would itself print out a prompt: 'Password:', and I would maybe never know that I had given my plaintext OS password to the application.

I might think I had, if the application then did something that did require sudo, and so the OS prompted; though even then I couldn't be sure - if it spawned another process for example I think it would be possible the OS would genuinely prompt twice, once for each child?

This is also true of GUIs, only very marginally (and against Kirckhoff) less so due to the need to replicate the OS' prompt.

Why isn't there some form of authentication - whatever that might look like - proving to me, the user, that the supposed OS, is the OS when e.g. prompting for my password?

  • how is this different from a GUI? does this problem not happen everywhere?
    – LvB
    May 17 '15 at 15:11
  • @LawrivanBuel What do you mean? I mentioned GUIs specifically in the question too.
    – OJFord
    May 17 '15 at 15:34
  • 1
    The OS never automatically prompts you for a password in a CLI. It tells you you need to run the program as root, and it's then your responsibility to do so. In fact, sudo isn't a part of the OS, it's just another program that happens to be setuid root.
    – cpast
    May 17 '15 at 15:35
  • @cpast It does on Mac at least. But I know what you mean, it doesn't always. Actually, not too sure what the criteria is.
    – OJFord
    May 17 '15 at 15:36
  • Are you sure that you weren't typing sudo XYZ?
    – cpast
    May 17 '15 at 15:37

When you type "sudo [software]", it will Always assume the software needs admin rights.

Thus, the OS will ask for the password, Before the process [software] has a chance to run at all.

However, you have a risk, and that is when you have sudo set to "remember" your authorization for a preset time. This is default behaviour, and I Think the time is set to 5 minutes. This can be disabled so sudo will Always ask for password 100% of the times.

Then if "authorization remember" is enabled, the software you are launching using sudo, could ask for your password, and you would Think its the sudo prompt. BUT REMEMBER: You have already authorized the software to run as root, so it can easily run "passwd [your username]" and change your password, if the software is malicious and want to maintain root access. Another thing the software can do, since its running as root, is to add a own user account with sudo rights, or just right out change the root password to something the software knows.

Once you authorize a software to run as root via sudo, you assume this software is completely legit and are completely 100 % trusted, so a OS->user auth would add no security whatsever.

As long as you type the Word "sudo", theres no way a application without root rights, could fool you into entering your password for a malicious process.

If a software however "self-sudo" when it needs elevated rights, like "brew install" without sudo, there is a possibility for the software to capture your password.

However, lets say the OS authenticate by Mutual authentication, by displaying a "security question" which only you and the OS knows the correct one. Then the malicious software could either capture the OS authentication by itself spawning the process and Reading from STDIN, or the software could simply Place itself as a "MITM" between the OS password request process and the user, using pipes, displaying the correct OS->user auth (even if the OS->user auth would be a one-time password system) AND also capturing the password.

Windows has solved this problem by requiring the user to press CTRL+ALT+DEL Before login. If a user spawned a process that looked like a login dialog and put this as full-screen in a attempt to capture for example administrator credentials, the administrator would either notice the CTRL+ALT+DEL prompt is missing, OR the administrator would press CTRL+ALT+DEL causing task manager to start instead, instantly giving away that the login dialog is fake.

However, this is only applicable for the first login dialog. You cannot do any protection/authentication for login requiest done while a user session is Active, that would be protected against any malicious processes running as that user.

  • This is not an accurate description of how sudo works. sudo is a program, no different from any other program, with no special hooks into the operating system. When you type sudo XYZ, it runs the program sudo with arguments XYZ; what sudo does is prompt you for your password (or authenticate you some other way), check sudoers for authorization, and then run seteuid to change its effective UID to the appropriate one before running exec on the command. The reason it can do all this is that it's installed as setuid root, but it doesn't have any special ties to the OS.
    – cpast
    May 18 '15 at 1:30
  • I know that. What I mean with "OS" in this context is that sudo belongs to the OS, its not a third-party program. Essentially, the whole OS consist of "normal programs". What I want to Point out is that sudo always run first, so if your authorization remember setting is 0 (eg do always ask for sudo password, even if you recently authenticated), then the first password prompt when typing sudo will ALWAYS be genuine. May 18 '15 at 1:38
  • Rereading the answer, yeah, I see what you're saying and it's right.
    – cpast
    May 18 '15 at 1:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.