4 ms·

The post does not back up its headline? How can a SHELL=/bin/false be bypassed via SSH? For the various kind of forwarding SSH supports, they all can be disabl

The post does not back up its headline? How can a SHELL=/bin/false be bypassed via SSH? For the various kind of forwarding SSH supports, they all can be disabled via sshd_config.

batch12 3y ago
Ive used something like ''' ssh -t user@host /bin/sh ''' To bypass shell restrictions in the past, but I'm not sure if that will work with your example.
- blueflow 3y ago
  This won't work because the command send to the server is not an argument vector, but a command string interpreted by the users login shell. `ssh -t user@remote /bin/sh asdf` would execute `/bin/false -c "/bin/sh asdf"` on the remote.
  - batch12 3y ago
    Makes sense, thanks for the clarification.
- LinuxBender 3y ago
  Feel free to try it out sftp share@ohblog.net (no pw) # grep share /etc/passwd /etc/shadow /etc/passwd:share:x:5002:5000::/data/sftp/share:/bin/false /etc/shadow:share::19614:::::: The partially redacted /etc/ssh/sshd_config is copied to /pub/ in the SFTP account. If you can bypass the restriction please do share how it was done. I don't offer bug bounties but I think people would find it interesting. OS is Alpine Linux. All CPU mitigations are disabled in the VM. No MAC As in no SElinux or AppArmor. I won't complain, just pretty please don't DDoS the server or anything that would make that VPS do work. Feel free to also tinker with the web and voice chat server on that node.
tyingq 3y ago
I think it's comparing to the "old days" when there was a more 1:1 relationship of service-on-a-port plus a specific userid. Because the article specifically calls out: "One of these services is SSH itself, since you can generally initiate SSH sessions and ask for port forwarding or other features that don't cause SSH to run the login shell" But, even that sort of falls apart because we also had inetd in the "old days", which spawned lots of different things as different users without invoking a login shell. Generally, the article seems to be lamenting that not everything is gated by userids and groups anymore. That's true, but it doesn't seem recent to me. Aside from inetd, I could (and did) massage kermit (or uucp, etc) into being a multi-service gateway in the 1980's. I suppose it's somewhat correct in the idea that figuring how any particular service limits rights is now very complicated. You have the old familiar stuff (users, groups). But now you also have virtual machines, containers, namespaces, capabilities. And things like seccomp and apparmor. Then, various sandboxing schemes within utilities, languages and frameworks or OS facilities like ebpf.
salzig 3y ago
For a port-forward with `-N` on client side. Besides that, I don’t know.
juped 3y ago
It seems to me (it's kinda unclear) that the article is talking mostly about various other things pulling users from /etc/passwd and the ssh thing is an aside. For anon ssh you can have e.g. Match User anonymous PasswordAuthentication yes PermitEmptyPasswords yes DisableForwarding yes PermitTTY no and possibly ForceCommand and ChrootDirectory depending on how you're sandboxing anonymous and to what; plus a restricted login shell (the above anonymous user of mine has gotsh, got's version of git-shell).
emmelaich 3y ago
You can pass various env vars with ssh, typically restricted to LANG and LC_*. But I vaguely remember that in the past it may have been anything, including SHELL.

The post does not back up its headline? How can a SHELL=/bin/false be bypassed via SSH? For the various kind of forwarding SSH supports, they all can be disabled via sshd_config.

batch12 3y ago

Ive used something like ''' ssh -t user@host /bin/sh ''' To bypass shell restrictions in the past, but I'm not sure if that will work with your example.

blueflow 3y ago
This won't work because the command send to the server is not an argument vector, but a command string interpreted by the users login shell. `ssh -t user@remote /bin/sh asdf` would execute `/bin/false -c "/bin/sh asdf"` on the remote.
- batch12 3y ago
  Makes sense, thanks for the clarification.
LinuxBender 3y ago
Feel free to try it out sftp share@ohblog.net (no pw) # grep share /etc/passwd /etc/shadow /etc/passwd:share:x:5002:5000::/data/sftp/share:/bin/false /etc/shadow:share::19614:::::: The partially redacted /etc/ssh/sshd_config is copied to /pub/ in the SFTP account. If you can bypass the restriction please do share how it was done. I don't offer bug bounties but I think people would find it interesting. OS is Alpine Linux. All CPU mitigations are disabled in the VM. No MAC As in no SElinux or AppArmor. I won't complain, just pretty please don't DDoS the server or anything that would make that VPS do work. Feel free to also tinker with the web and voice chat server on that node.

tyingq 3y ago

I think it's comparing to the "old days" when there was a more 1:1 relationship of service-on-a-port plus a specific userid. Because the article specifically calls out: "One of these services is SSH itself, since you can generally initiate SSH sessions and ask for port forwarding or other features that don't cause SSH to run the login shell" But, even that sort of falls apart because we also had inetd in the "old days", which spawned lots of different things as different users without invoking a login shell. Generally, the article seems to be lamenting that not everything is gated by userids and groups anymore. That's true, but it doesn't seem recent to me. Aside from inetd, I could (and did) massage kermit (or uucp, etc) into being a multi-service gateway in the 1980's. I suppose it's somewhat correct in the idea that figuring how any particular service limits rights is now very complicated. You have the old familiar stuff (users, groups). But now you also have virtual machines, containers, namespaces, capabilities. And things like seccomp and apparmor. Then, various sandboxing schemes within utilities, languages and frameworks or OS facilities like ebpf.

salzig 3y ago

For a port-forward with `-N` on client side. Besides that, I don’t know.

juped 3y ago

It seems to me (it's kinda unclear) that the article is talking mostly about various other things pulling users from /etc/passwd and the ssh thing is an aside. For anon ssh you can have e.g. Match User anonymous PasswordAuthentication yes PermitEmptyPasswords yes DisableForwarding yes PermitTTY no and possibly ForceCommand and ChrootDirectory depending on how you're sandboxing anonymous and to what; plus a restricted login shell (the above anonymous user of mine has gotsh, got's version of git-shell).

emmelaich 3y ago

You can pass various env vars with ssh, typically restricted to LANG and LC_*. But I vaguely remember that in the past it may have been anything, including SHELL.