sudo option "tty_tickets" gives false sense of security due to reused pts numbers

As this issue seems somewhat hard to remedy completely, I decided to comment on possible remedies separately.

It would seem beneficial that unused tty_tickets from '/var/run/sudo/yourusername' should be cleared. More specifically, the tickets for such tty's and pts's that _are not in use_ at any point in time should be cleared.

Now, what process could be responsible for doing this?

A. The kernel and "devpts", which is responsible for assigning new pts's at '/dev/pts/*'. It could be argued that this would be the right place, to tackle the authorisation issue at a low level. It could also be argued the opposite, that authorisation issues do not belong here, that it is not the kernel's job to do things for sudo. This would mean that this should be handled in userspace.

B. A root level "sudo daemon" that would keep an eye on tty's and pts's on one hand and sudo's tty_tickets on the other hand. Whenever a terminal or a pseudo-terminal is freed, the daemon would clear the appropriate sudo tty_ticket for all users, and possibly make a note in a log. (The tty's probably would need to be handled differently than the pts's.)

C. For graphical applications requiring sudo access, the application that granted the access could also clear the ticket when the sudo capability isn't needed anymore. (E.g. 'kdesu' or 'kdesud'. It seems the 'kdesud' is used for caching the password given to 'kdesu'.)

D. A work-around is to use "timestamp_timeout=0" in '/etc/sudoers', but this takes away a usability feature from sudo.

A couple non-working "solutions" follow:
E. "The command 'sudo' should be responsible for clearing the ticket." This can't be done, because sudo is not running when the terminal is freed.
F. "The terminal or 'bash' should be responsible." This can't be done because the terminal or the shell are not root-level processes, and so can't remove root-owned tty_tickets.

One more possible solution / workaround:
G. For (primarily) _non_-graphical use-cases of sudo, and to clean-up after graphical applications that lack this functionality -> A new usage option for 'sudo' that is like 'sudo -K' but, instead of only operating on the ticket of the current terminal, cleans _all_ the tickets in '/var/run/sudo/yourusername/'.

The possible downside is that this requires that the user manually (or semi-manually) evokes it. The upside is the same as that stated in 'man sudo' for 'sudo -k' (and, implied, for 'sudo -K'): "This option does not require a password and was added to allow a user to revoke sudo permissions from a .logout file."

As demonstrated by this report and some others, it is quite easy and all the more common to have a number of terminals open, and to use 'sudo' in those or through graphical means. In view of this, I think the option presented here would often prove useful. I wouldn't actually mind if 'sudo -K' would operate on all of the current user's tickets by default.

Thanks for this well-described bug report! I wonder if some people would describe the "authenticated old tty" issue as a "feature"? I would tend to agree, though, that it is surprising to open a terminal and not get prompted. I find your "Issue 2" the most compelling -- this should not be allowed to happen.

As you've hinted, the "original" solution, in the design of sudo in general, was for users to add "sudo -K" to their ~/.bash_logout file. However, I suspect that isn't a proper solution (especially for gksu/kdesu). I haven't checked, but if udev receives notifications about pts devices being removed, perhaps it could be responsible for running "sudo -K" (or something similar)? That might solve all three scenarios, though I'm curious about the double pts allocation with kdesu.

The double pts requirement with 'kdesu' could (even) be by design to "circumvent" the issue of old tickets lying around (compare with the bugs referenced above), but this would be bad design. It seems more likely, though, that it is just a side effect of starting a process and then forking it into different parts that have different tasks.

Also, what is problematic with the cases under "Issue 1", is that these cross the border between graphical and command line sudo access, which is very unintuitive for the user. It's OK if 'kdesu' remembers that I've just given my password, _if_ I've accepted this in its options. However, having a sudo capable shell isn't really OK, if I've only given my password to 'kdesu'. And vice versa.

(As a parenthesis: A real-life case I can think of is wanting to try out and './install' some 3rd party software, which has its own installation method (be it text-based or graphical). This could even have the option to _either_ install globally (if given the permissions) or as a fall-back to install locally for the user only. A password prompt at this point is very indicative to the user about where exactly things will be installed, and missing the password prompt can lead, at best, to confusion.)

After talking to gregkh and hpa, it seems there are no udev events for pts add/remove. :( To do this, the pts kernel could would need to be written to use kobjects.

That should read "the pts kernel code would need to be written to use kobjects."

I'm wondering - should this report be marked as concerning also 'kdesu', i.e. "kdebase", due to it leaving behind a valid sudo ticket?

Also, I am curious to know - does 'gksudo' leave behind a valid sudo ticket, or is the ticket cleared afterwards? (And, consequently, if a ticket is left behind, should this report be marked as also concerning the package providing 'gksudo'?)

kko: No, this only affects sudo and perhaps udev -- things like kdesu that build on top of sudo do not have any particular privileges and cannot fiddle with tickets.

Thank you for the information. Taking a look at kdesu's permissions I see what you mean.

I see a few options for dealing with console log-outs:

1) Add "sudo -K" to /etc/skel/.bash_logout via patch to bash pkg. (This doesn't catch upgrades, and doesn't handle people not using bash.)

2) Dig into pam's session management and write new module to be added as login and ssh required "session" modules. (Seems a bit sloppy.)

3) Using a recent patch to mainline, write a logout-watching daemon that cleans up after sudo when a pts goes away (this seems really like too heavy a solution)

4) Patch the pts code to use kobjects and hook up a listener to "remove" events. (This is a lot of work.)

As for the GUI apps, I think sudo (and the GUI su-ing apps) should be patched to add something like "--single-shot", where no tty-based ticket is left behind.

Incidentally, I was pondering this too, after my last comment, so I'll comment on these suggestions.

For GUI apps, I agree with you. It should be easy for 'kdesu' or 'gksudo' to:
- Obtain needed privileges and launch the app requiring sudo privileges.
- Immediately afterwards call 'sudo -K' on the appropriate pts.

This should take care of the GUI side of the problem - see further though.

I don't really understand how 'kdesud' is supposed to work. I suppose it just sits there for as long as kdesu is configured to remember the password given to it, and is supposed to catch further launches of 'kdesu'. (It doesn't for me, so I wonder _why_ it is launched at all, but it's a different issue.) I don't know if 'kdesud' needs the ticket at all - according to 'man kdesu' it wouldn't: "The passwords are NOT written to disk, but stored in memory using a special program, kdesud."

If the ticket isn't needed to implement the grace period (i.e. remembering the password for a set time) functionality in GUI sudo apps, the option "--single-shot" definitely sounds like a cleaner way to implement this.

For the CLI, I tend to agree that your suggestions 3 and 4 seem heavy, although number 4 would probably be a good solution. I can't really say anything about suggestion 2.

I came up with the same thought as your suggestion 1 also. Basically, I thought it would be useful, but while trying it out I found a serious drawback. Unfortunately, .bash_logout is only handled for _login_ shells, i.e. it is not executed for inter-active shells from Konsole. (People can also remove '~/.bash_logout', but then it's their choice. I also wondered about the case where the shell (e.g. hanged and) got terminated in an abnormal way and it couldn't execute the logout script - in this case a solution not dependent on the shell would be more reliable.)

Calling sudo -K from a GUI sudo wrapper is a bad idea. It would invalidate any tickets for other terminals as well. Solutions #2 and #4 seem reasonable. I think #2 would be easier to do, but I'm not an expert on any of this.

FYI, gksu (as of libgksu version 2.0.11) allocates a new pseudoterminal, runs sudo -v to acquire a token, then uses g_spawn_sync in the parent process once the authentication is successful. (This allows gksu to be executed with the 'Defaults requiretty' option, which is enabled by default on RHEL.) Obviously, this fix doesn't work properly with the tty_tickets option. I'm going to write another patch to try and address this issue.

Until then, I wouldn't be using the new libgksu in Karmic!

I have part of idea of another workaround for pty (but not for tty).

Open console:
$ ls -l --full-time --time=ctime `tty`
crw------- 1 darkk tty 136, 2 2009-11-14 15:41:39.260720360 +0600 /dev/pts/2

Close console, open console again:
$ ls -l --full-time --time=ctime `tty`
crw------- 1 darkk tty 136, 2 2009-11-14 15:43:31.320713474 +0600 /dev/pts/2

So ticket may include ctime of pty.

On the other hand, malicious attacker can change ctime of the /dev/pts/2 and he may get correct ctime watching /dev/pts (he can't get ctime from ticket data). I don't know if it may be avoided using something like POSIX ACL's and I assume that POSIX ACL's are not supported by ptsfs. Maybe someone has better idea.

This report is now a few years old and I'm seeing an interesting behavior of sudo:

1. First I'm Cleaning /var/lib/sudo/$USER as root with "rm -rf /var/lib/sudo/sworddragon/*".
2. Then I'm opening a terminal with my user account.
3. Typing tty returns /dev/pts/2.
4. Then I'm typing "sudo true" and entering my correct password.
5. Typing "md5sum /var/lib/sudo/sworddragon/2" as root returns "6ec673eac24f4e2fc0c5fa149eebfcef /var/lib/sudo/sworddragon/2"
6. Then I'm closing the terminal on /dev/pts/2 and opening it again.
7. Typing tty returns /dev/pts/2.
8. On typing sudo true I'm asked again for my password.
9. Instead of typing my password I'm typing now as root again "md5sum /var/lib/sudo/sworddragon/2" which returns "6ec673eac24f4e2fc0c5fa149eebfcef /var/lib/sudo/sworddragon/2".
10. Typing "ls -a /var/lib/sudo/sworddragon" as root returns ". .. 2".

This means even on getting the same pts without expiring of /var/lib/sudo/sworddragon/2 sudo asks me for my password. Can somebody tell me where is hiding the security mechanism here? Also are the cases in this ticket still a problem or are they maybe already fixed?

Sworddragon, I believe this code from plugins/sudoers/check.c in check_user() prevents the tty reuse problem:

    /* Stash the tty's ctime for tty ticket comparison. */
    if (def_tty_tickets && user_ttypath && stat(user_ttypath, &sb) == 0) {
        tty_info.dev = sb.st_dev;
        tty_info.ino = sb.st_ino;
        tty_info.rdev = sb.st_rdev;
        if (tty_is_devpts(user_ttypath))
            ctim_get(&sb, &tty_info.ctime);
    }

    if (build_timestamp(&timestampdir, &timestampfile) == -1) {
        rval = -1;
        goto done;
    }

    status = timestamp_status(timestampdir, timestampfile, user_name,
        TS_MAKE_DIRS);

    if (status != TS_CURRENT || ISSET(validated, FLAG_CHECK_USER)) {
        /* Bail out if we are non-interactive and a password is required */
        if (ISSET(mode, MODE_NONINTERACTIVE)) {
            warningx(_("sorry, a password is required to run %s"), getprogname());
            rval = -1;
            goto done;
        }

        /* XXX - should not lecture if askpass helper is being used. */
        lecture(status);

        /* Expand any escapes in the prompt. */
        prompt = expand_prompt(user_prompt ? user_prompt : def_passprompt,
            user_name, user_shost);

        rval = verify_user(auth_pw, prompt);
    }
    /* Only update timestamp if user was validated. */
    if (rval == TRUE && ISSET(validated, VALIDATE_OK) &&
        !ISSET(mode, MODE_IGNORE_TICKET) && status != TS_ERROR)
        update_timestamp(timestampdir, timestampfile);

Thanks

Thanks for the answer. If I'm not wrong ctime has a nanosecond resolution. The only way to abuse this is if:

- The tty/pts gets closed.
- The time adjusts to the past (for example due to ntp).
- The next opened console/terminal gets the same number and is created exactly at the same time.

While this is theoretically possible it should only be seen as an extremely rare race-condition. Also normally while the user opens a terminal, types sudo and enters his password at least a few seconds will be gone. Normally the adjustment of ntp is only a few milliseconds. If I'm not wrong here too ntp refuses to adjust the time to a too far point.

So this is a very nice security mechanism of sudo (does gksudo build on sudo too and benefit from this?).

I might be overstepping here, but I'm marking this as Fix Released. I can confirm, as with comment #16, that this is no longer an issue. I'm on Vivid.