libutempter API does not handle usernames correctly

[saurik]

(Note: This is long, and meandering, and wasn't even typed quite in the order I finally put it together in, and as so is even more overly confusing than this insanely long run-on sentence that I've stuck at the beginning of this issue so as to provide a warning that the content is largely incomprehensible... frowny.)

When you log into a system, you do so with a username, which is stored in utmp. Programs that care about the "logged in user"--which might be unrelated to the user that owns the currently executing process--can then look up that username using getlogin(), which goes back into utmp to look up the data.

The reason why programs that want to know who is logged in use getlogin, a function that returns a username (as opposed to a function that returns a uid and then getpwnam), is that the username->uid->username mapping might not successfully round-trip on any given system.

On my servers, I have multiple login aliases to the same account. This allows me to provide multiple people root access, and yet have them all maintain separate passwords, separate home directories (so as to use personal settings for .vimrc, not for storing private data), separate hardware two-factor authentication token seeds, and separate screen sessions (which screen organizes by way of the logged-in username).

Meanwhile, on some devices, you simply can't perform the uid->username lookup reliably because the information is entirely not present on your local system (due to usage of an external or remote authentication system) or is simply not accessible to your user account.

(This situation actually comes up commonly on Android devices, as the username mapping table is stored as a hardcoded array in various places in bionic. If you have processes sitting in different chroots, especially if they are using glibc, you will get failures attempting to do reverse lookups.)

Put differently, the core problem is simply that the uid->username mapping is non-normative: users do not log in with uids, they log in with usernames. The mechanisms for handling the reverse lookup have no guarantee to accurately reflect the result of the forward lookup. If you want to replicate the process later, you have to start from the original username.

Given this, the fundamental mistake that libutempter is then making is that the API doesn't even seem to allow the daemon to pass the original username used to look up the account: instead, it insists (I currently assume for a security reason, due to its use case) upon attempting to auto-detect the username using getpwuid(geteuid()) in a separately-executed helper process.

This result, though, simply doesn't work if you are dealing with any of the above situations. In my case, if I log in with mosh, I have access to none of my screen sessions (which actually makes mosh useless to me ;P), as utmp has the wrong username stored in it (which causes screen to look in someone else's folder to find my active sessions).

So, on the one hand, this seems like "bug in libutempter", but it isn't really the implementation that is the problem: it is in fact the API of libutempter itself that contains a design flaw. Given its API, I'm not even certain if it is really a bug: it seems like utempter may in fact supposed to only be used as a fallback for applications that don't have root access.

In fact, that does seem to be why the library exists, and this seems to be exactly what mosh is: an unpriviledged process that seems to want to edit utmp (seemingly to unregister and reregister the user attached to the session so they aren't considered logged in while disconnected): it needs to go through this helper API (and it can't just let sshd manage it as sshd insists on deleting the entry when the original session disconnects).

Looking at it from this level, we can compare the behavior to tmux and screen. The behavior of tmux is ludicrous: it allocates peudo-terminals without adding them to utmp, so if you call getlogin() you get back NULL, causing programs that rely on that (such as screen, humorously) to have to fall back to incorrectly doing uid->username reverse mappings.

What screen does is more interesting: it has a bunch of code for using libutempter, but will only use it if it needs to: if it has enough privileges to directly access utmp it avoids relying on the setuid wrappers, seemingly because of limitations with the API (there are multiple comments in the code bemoaning "login slots" not working correctly).

Instead, screen seems to simply be setgid utmp, which allows it to have access to the utmp database. Is there a reason I'm not understanding as to why mosh can't also be setgid utmp, and can't itself also modify the utmp database like screen does? I believe that this can be used to fix the login name issue (as the login name can be copied from the original pty through to the login shell).

[keithw]

Thanks for this detailed writeup. As you've touched on, there's no fundamental reason mosh-server couldn't also be setgid utmp and attempt to munge utmp directly (as screen does).

I think the main considerations are:

• It's nice to have no privileged code in the project
• utmp and utmpx formats vary, so it's nice to abstract this away to a system facility rather than trying to become masters in the Linux/FreeBSD/OS X/Android/etc. particularities
• this is a particularly arcane area and part of the reason for writing mosh from scratch was that I didn't want the code to end up resembling screen's or tmux's. :-)

But if this is a problem for you, maybe we can work out a solution. The long-term approach would be to augment the utempter API as you describe -- the application could provide an advisory username which the helper could verify maps to the correct UID before using it.

[kmcallister]

I would be really unhappy for any part of Mosh to be setuid or setgid anything. It's a major source of security holes, and would impose a severe burden on developers to avoid those.

Is there maybe a simpler workaround for your use case, such as telling screen which directory to look in?

A variety of issues (such as #47 and #25) would be mitigated by an option to leave the initial SSH connection open, in some kind of suspended animation. If we can think of a good way to do this, we could use it here as well.

[saurik]

I don't know if you've actually looked at libutempter, but it only supports Linux/FreeBSD, and does so with a couple hundred lines of code, almost all of which are braces, whitespace, and debug printf calls that are #ifdef'd out.

In fact, it doesn't even support OS X, which is why issue #61 is currently open. In essence, I would strongly argue that using this library does not actually handle either of your two longer concerns: it doesn't actually abstract anything.

The only thing it provides is a privilege separation, and that same privilege separation can be maintained by providing a similar feature inside of mosh: it is just a matter of having a tiny binary that does nothing but edit utmp (and please, for the sake of the mempodipper exploit: doesn't echo anything controlled by the user to stderr or stdout ;P).

I mean, seriously: libutempter only supports two platforms anyway, so the result is either mosh reimplements it (without the egregious formatting, dropping it down to maybe 30 lines of code) or ends up having to do all of that work anyway to get to actually become portable.

[saurik]

Leaving the initial SSH connection open isn't useful because it is running over TCP: if you lose your connection or need to switch to a different source of network connectivity, you will get disconnected and lose whatever benefits you had from it.

[kmcallister]

Leaving the initial SSH connection open isn't useful because it is running over TCP: if you lose your connection or need to switch to a different source of network connectivity, you will get disconnected and lose whatever benefits you had from it.

Right, I was thinking we would need to do something tricky to prevent that. I don't know what, yet.

[saurik]

FWIW, I was looking into that earlier (in my attempts to figure out a cuter workaround to this utmp issue that was able to flex OpenSSH's actually-portable and actually-correct implementation of utmp to replace libutempter), and it does not seem possible (but I could be wrong); it seems like OpenSSH closes out the session and destroys related state when the connection dies.

[keithw]

Hypothetically, if we did develop our own setgid utempter replacement, how would we deploy it on platforms like homebrew and MacPorts, where the users are typically compiling and installing as an unprivileged user? (I don't really know how "screen" is installed there either.)

[saurik]

MacPorts and Fink are installed as root. I generally frown on the Homebrew security model (which encourages users to add /usr/local/bin to their path and make it writable by your user account... you really should never have a path you can write to on your path... it is just asking for trouble, although it can make my job somewhat easier at times ;P I'm willing to believe I misunderstand it, however); looking at its base formula set it contains neither OpenSSH nor screen (possibly as both already come with Mac OS X): it might simply not be prepared to handle packages that require utmp access. I can do a more comprehensive examination later (assuming someone else doesn't beat me to it).

[quentinmit]

It's not clear to me that it's possible to directly control utmp on OS X; it provides a pututxline function, but I'm not sure if that works. screen, for example, has been patched by Apple to call /bin/login instead of frobbing utmp. In any event, pututxline must be called from a setuid root program on OS X, alas.

[saurik]

@quentinmit While Apple would prefer you to use /bin/login (a stance that I maintain is actually more correct), utmpx actually does still work (and Apple continues to use it directly for OpenSSH); thought one might question if that is a temporary situation, and whether a subsequent version of the OS will mark it as deprecated for a later removal.