New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
passing $MOSH_KEY in environment a shaky choice security-wise #156
Comments
We're aware of this issue, but thank you for giving us a report about AIX. We've been discussing what to do about it; at minimum we will add a warning in the build instructions. |
I guess one question would be is it worth to have the client split into separate perl and C++ halves at all? Just glancing at the perl script it doesn't look like it's doing anything that would be heinous to implement in C++. Then you could possibly roll the whole thing up into one binary (even the server could be just a command line flag like "--run-as-server" similar to how tools like rdist/rsync work) Anyway -- great tool guys. Solves a real problem in a creative way. I'm looking forward to seeing its evolution. |
Indeed, we have a prototype of the wrapper in C++, and we've discussed merging it with |
We're considering merging the wrapper with |
For the record, some while back we discovered (on IRC?) that OpenBSD 5.2 has this exact security exposure of leaking the environment to other local users (it was fixed shortly after that release, though). So this is not a theoretical security flaw. Ironically I'd implemented my pull request #521 before we discovered the OpenBSD issue. |
The other night I realized that procfs on Linux allows anyone with permission to easily get access to that pipe and maybe read the key before mosh-client does. Urrgh. I do not love procfs. I think this is still a smaller exposure than using environment variables, but the difference is lot less clear cut than it was to me before. |
In response to mitchblank's earlier comment -- I got here via https://unix.stackexchange.com/a/369568/117549 -- AIX, at least by 6100-09, and also confirmed on 7.2, now prevents non-root users from seeing the environment of other users' processes with the "ps ewwwax" command. |
Hello. Continuing on @cgull comment. IssueYes /proc can be used to snoop around process activity, including messing with file descriptors passed between processed (e.g. /proc and directory permissions [LWN.net] -- not the same issue). SolutionThe good news is there appears to be a solution: call This is used by programs such as
which outputs:
See discussion on:
Calling What about mosh?
Setting dumpable to false with all its effects seems reasonable for a process that handles security keys, isn't it? What do you think? |
FYI mosh-client and mosh-server do use Lines 291 to 308 in ddb5fd9
|
Background: in the process image argv[] and envp[] are stored in the same way, next to each other. In "classic" UNIXes /usr/bin/ps was typically setgid "kmem" (or similar group), which allowed it to dig around in /dev/kmem to read information about the active processes. This included the ability to read the process arguments AND the environment, of all users on the system.
These days these "privileged ps hacks" are largely behind us: UNIX systems have all come up with different ways of querying such information (/proc on Linux, etc) I think all(?) of these consider a process's environment only to be readable by its uid. Thus, security-sensitive data like passwords in the environment aren't leaked.
However, the old ways aren't 100% dead. Just as an example, here's an example from an AIX 5.2 machine I have access to, running as a non-root user:
Today, mosh seems to be only on Linux/OSX/FreeBSD but if it catches on I'm afraid it will end up on some platform that still uses the old-school UNIX "everybody can see anybody's environment variables" model. Since $MOSH_KEY is basically the keys-to-the-kingdom this would be a humungous hole.
There's a well established pattern for dealing with this: send the key over a pipe. So the call looks like:
...and the parent process has a pipe open on fd=3 when it exec's mosh-client which it can write the key to.
The text was updated successfully, but these errors were encountered: