Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support transmission of environment variables #398
The SSH protocol allows the client to transmit environment variables to
This patch extends the Client and Channel interface to allow
In order to use this feature the SSH server must accept environment
Dec 1, 2016
1 check passed
The exception seems to do with the eventing stuff,
Seems one of the specific problems with
It's still unclear to me exactly how this sort of attack works against the sshd, because I don't know exactly what happens between recipient of "please exec this command for me" and creation of the user-owned subprocess. I'm struggling to figure out how the root-privileged sshd is the one executing an actual,
Put another way, why is this exploit not simply a vanilla local privilege escalation? Why does it have to go via an sshd?
(Note - I am just digging into the security implications of this for my own edification; it's not possible to change the rest of the world so I still need to drop those warnings/notices into the docs. Just wondering whether I can feasibly use this particular feature myself in higher-level code or not...)
Took another tack to see exactly how the env vars set with the
So all of this so far is, as expected, updating a memory value holding the env var map. Question is what's done with this array?
Looks like the standard reference implementation (OpenSSH client) sends the
While it would be nice to be able to tell the client which (if any) Env requests failed, that would rely on fixing the uncovered buggy behavior of Channel._request_failed(). In the interim, changing the request's want_reply=False looks like it might be an adequate solution for this, and buy time to properly address the Channel._request_failed() handling, which looks like a big enough gaffe to warrant its own tracking issue :)
Yea, privileges are dropped well before any of that stuff happens; once the sshd main process accepts connections it authenticates, drops privileges, sets up user context for the connected user, and spawns a new child that does the rest of the work re: handling subsequent messages from the client. So everything from acceptance of the
Which brings me back to: how is this an exploitable channel if it's functionally identical in terms of privileges to a user running things in a local shell? Re: the specific
So I'm starting to wonder if the info out there re: why AcceptEnv is considered insecure (I started at http://serverfault.com/questions/427522/why-is-acceptenv-considered-insecure...maybe all this poking has been a SO-induced time waster of sorts. Though I now know the OpenSSH codebase much better...) is inaccurate.
Which is pretty vague and I'm interpreting it to mean "hey, if you have your login or ssh keys or etc configured such that users can only run certain programs / run in a certain environment,
Ubuntu's manpage has identical language...as does OpenBSD's: http://man.openbsd.org/sshd_config
EDIT: ah, ok. Part of the problem is that the SO poster conflated
@radssh Good catch on the reference client implementation. I'd guess that matching it on our end would turn rejections into silent failures? Certainly seems the case with
even with a default/limited
So that sounds like another worthwhile change to make to this, if orthogonal to my own personal quandary :D
So for better or worse it appears both of these sshd options have similar security impact.
More generic googling about this issue finds a seeming confirmation of my assumptions here: http://serverfault.com/a/527648 - the idea here is that if you're locking down SSH to specific commands or subsystems, allowing
Even in that case I'm wondering exactly what limited access could include
But at least it seems I'm not missing something: in the "typical" use case of "your users are all shell users",