[gusty] [sudo command &] shows password!

[Bastiaan Wakkie]

Binary package hint: sudo

Hi,

After todays update I have a strange sudo problem that needs to be solved:

if you enter a sudo command like this...

# sudo ... &

...and you did not login before via sudo your password is written on the screen if you type it and all fails.

If you do it with out the '&' it works normally
# sudo ...
[sudo] password for me:

So if you do not play attention and just look at your keyboard while typing, like I do ;-), you just reveal your password!

[Sarah Kowalik (hobbsee-deactivatedaccount)]

I cant reproduce this. Can you repeat this bug?

[Sarah Kowalik (hobbsee-deactivatedaccount)]

erk, i see now!

[Ian Jackson (ijackson)]

What is happening here is this:

 * sudo & runs sudo as a background process. The shell and
   sudo race to each print their prompt.
 * sudo tries to read the password from the terminal. At
   this point it receives a SIGTSTP from the kernel tty subsystem
   due to the terminal having the ttin flag set (ie, issue TSTP on
   terminal input attempt by background process group).
 * if you're lucky your shell will print a message about this
   immediately, but this is not guaranteed. And in any case it is
   confusing.

The solution is that sudo ought to make a non-blocking read of its
terminal _before_ printing the prompt. Then, sudo would get SIGTSTP
straight away and you'd see this:

ian@anarres:~ $ sudo bash &
[1] 7745
ian@anarres:~ $

[1]+ Stopped sudo bash
ian@anarres:~ $

This change ought to be made in whatever library sudo is using for
password prompting.

Ian.

[Bastiaan Wakkie (bwakkie)]

Ian,
In your example you do not log in
it is like this now...

me@mycomp:~$ sudo bash &
[1] 12101
me@mycomp:~$ [sudo] password for me:
mypassword!!!!

[1]+ Stopped sudo bash
bash: mypassword: command not found

[1]+ Stopped sudo bash
me@mycomp:~$

...with a result that I can't start it. But I guess you got the point. Quick workaround is ...
me@mycomp:~$ sudo bash
me@mycomp:~$ [sudo] password for me:
root@mycomp:~$ exit
me@mycomp:~$ sudo bash &
[2] 12299
me@mycomp:~$

cheers,

Bastiaan

[Ian Jackson (ijackson)]

Bastiaan writes ("[Bug 130636] Re: [gusty] [sudo command &] shows password!"):
> [stuff]

I'm sorry to say I don't think that adds much towards helping fixing
the bug. My transcript was a demonstration of what the results of
`sudo something &' would be _after_ the change I proposed.

Having said that I think it might be helpful if I were to mention the
command `fg' of which I think you are unaware. Full details are in
the manpage for bash and a short version in `help fg' froom a bash
prompt. Anyone who uses & should also know aboug fg, ^Z and bg.

Ian.

[Bastiaan Wakkie (bwakkie)]

I asked the sudo team and they fixed it!

here a quote from Todd C. Miller:
"It turns out that this is fairly easy to detect without using
a non-blocking read. I've just committed a change to cvs which
will appear in sudo 1.6.9p6."

So it will be fixed in build 1.6.9p6

[Bastiaan Wakkie (bwakkie)]

Upgrade to version 1.6.9p6

[Martin Pitt (pitti)]

sudo (1.6.9p6-1ubuntu1) hardy; urgency=low

  * Merge with Debian unstable. Remaining Ubuntu changes:
    - debian/prerm: Abort package removal if there is no root password.
      Forwarded to Debian #451241.
    - sudoers: Add some explanatory text why it is a REALLY good idea to use
      visudo. (LP #11620)
      Forwarded upstream: http://www.gratisoft.us/bugzilla/show_bug.cgi?id=269
    - debian/rules: Disable lecture, enable tty_tickets by default.
    - debian/rules: Configure less confusing default password prompt to point
      out that it is sudo asking for the user's password, as opposed to
      another program like ssh, or asking for the root password. (LP #8556)
      Forwarded to Debian #343268.
    - Add debian/sudo_root.8: Explanation of root handling through sudo.
      Install it in debian/rules.
    - sudo.c: If the user successfully authenticated and he is in the 'admin'
      group, then create a stamp ~/.sudo_as_admin_successful. Our default bash
      profile checks for this and displays a short intro about sudo if the
      flag is not present.
  * New upstream version 1.6.9 fixes the following bugs:
    - Does not ask for password any more if stdin is not a terminal.
      (LP: #130636)
    - sudo -k/-K does not fail any more if timestamp is in the future.
      (LP: #43233)
  * Drop our very intrusive patch for selectively cleaning the environment
    based on whether the user can execute all commands or only some. Debian
    and upstream now default to cleaning the environment unconditionally and
    provide option -E and the SETENV tag to override it.
    Instead, do a tinpy patch to parse.yacc which enables SETENV implicitly
    for 'ALL' commands.
    Forwarded upstream: http://www.gratisoft.us/bugzilla/show_bug.cgi?id=268
  * sudo.c: Disable i18n for now (upstream enabled it in 1.6.9), since this
    causes PAM to output localized password prompts, which in turn breaks -p
    and --with-passprompt, which finally breaks gksu. See
    http://www.gratisoft.us/bugzilla/show_bug.cgi?id=270 for details.

sudo (1.6.9p6-1) unstable; urgency=low

  * new upstream version, closes: #442815, #446146, #438699, #435768, #435314
    closes: #434832, #434608, #430382
  * eliminate the now-redundant init.d scripts, closes: #397090
  * fix typo in TROUBLESHOOTING file, closes: #439624

 -- Martin Pitt <email address hidden> Wed, 14 Nov 2007 14:23:47 +0100

[Martin Zuther (mzuther)]

Hello!

I run an up-to-date Gutsy, and my version of sudo (1.6.8p12-5ubuntu2) still shows the bug. I think it is a serious security problem for the everyday user, because if you are unaware of the problem and encounter it for the first time, anybody happening to look over your shoulder knows your root password. Therefore I vote for a fix in Gutsy, not only in Hardy!

Thanks,

Martin

[Daanemanz (daanemanz)]

I'm running an up-to-date Intrepid Ibex 32-bit and the bug is still present. Shouldn't this have been fixed a long time ago? I saw the problem arise when executing a command on a remote machine:

me@mylaptop:~$ ssh server 'sudo apt-get autoremove'
[sudo] password for daan: [my password in clear text]

I have used ssh-copy-id for this server and I have openssh-client version 1:5.1p1-3ubuntu1 and sudo version 1.6.9p17-1ubuntu2.1 installed.

[Jamie Strandboge (jdstrand)]

Daanemanz, this is not the same issue. When running a command in the way you specified, you must specify the '-t' option to ssh. See 'man ssh' for details.

[Kees Cook (kees)]

https://wiki.ubuntu.com/SecurityTeam/FAQ#SSH

[Daanemanz (daanemanz)]

Thanks a lot... but still, IMHO, for the unexperienced user, I'd recommend to use this option by default.

But this solves my problem, thanks a lot!

[Adrian (ruewan)]

This is happening again for me in 11.04 and 11.10

[Andreas Moog (ampelbein)]

Doesn't happen for me in the versions you mentioned, adrian:

andreas@anubis:~/temp$ sudo bash &
[1] 23233
andreas@anubis:~/temp$ fg
sudo bash
[sudo] password for andreas:

[Adrian (ruewan)]

Andreas I think it is happening for you as well. It should have requested the password the first time when you typed sudo bash & but it not.

for example
adrian@adrian-Latitude-E6420:~$ sudo gedit &
[1] 3429
adrian@adrian-Latitude-E6420:~$ sudo blah
[sudo] password for adrian:
sudo: blah: command not found

[1]+ Stopped sudo gedit
adrian@adrian-Latitude-E6420:~$ sudo gedit &
[2] 3433

The first time when I try to run gedit with the & it does not bring up the gedit window and did not ask me for my password
when i type sudo blah without the & it asks me for my password
now that i have authenticated for the blah command without the & i can type sudo gedit & and the gedit window opens.

[Adrian (ruewan)]

Oh, I think i am talking about a different bug