10 ms·

Don't forget to disable sftp in your sshd_config. and ssh port forwarding. and hopefully there's no sneaky way that an attacker can push an environment variable

Don't forget to disable sftp in your sshd_config. and ssh port forwarding. and hopefully there's no sneaky way that an attacker can push an environment variable to break something like with LD_PRELOAD, and are you sure there are no directly/indirectly exploitable bugs/omissions in your script logic for invoking complex commands like git, and that your distributed filesystem works quickly across a few million home folders for your authorized_keys files, ...

jolmg 3y ago
EDIT: Crap. You're right. Port forwarding worked... So there's that. `ssh -J userfoo@localhost other-place` also worked... I would imagine that's all able to be disabled, but I see that the user is not fundamentally limited to what the shell allows. That's disappointing. I thought it would wrap everything in `custom-shell.sh -c` calls like it does with the sftp and scp servers. I imagine/hope that under a default configuration one is still not able to touch the contents of the server if the shell doesn't permit it, but being able to use it as a proxy or listen on its ports is not what I expected. ORIG_REPLY: > Don't forget to disable sftp in your sshd_config Doing `strace -fp $(pgrep sshd)` then `sftp userfoo@localhost` in another terminal, I see: $ sftp userfoo@localhost Connection closed. Connection closed $ then in the `strace` output: [pid 408173] execve("/tmp/custom-shell.sh", ["custom-shell.sh", "-c", "/usr/lib/ssh/sftp-server"], 0x55c5f3bae0d0 /* 14 vars */) = 0 [pid 408173] write(1, "/usr/lib/ssh/sftp-server: unknown command\n", 42) = 42 As far as I understand, SSH's security of what a user can do is completely based on what the shell permits the user to do. > are you sure there are no directly/indirectly exploitable bugs/omissions in your script logic for invoking complex commands like git Including a ssh server in the same executable doesn't save you from such bugs. > and that your distributed filesystem works quickly across a few million home folders for your authorized_keys files OpenSSH's sshd seems quite flexible in ways to authenticate users. I don't think having a home folder per user is necessary if you don't want it. > and hopefully there's no sneaky way that an attacker can push an environment variable to break something like with LD_PRELOAD SSH's default is to not accept the client's environment, and this shell itself provides no way to manipulate them. They can be nonexistent in the shell's interface if you don't want them. I put the script so someone can offer some concrete way (as in show me some code) to bypass it in a way that having a custom integrated SSH server would prevent it. I'd love to see a `ssh/sftp userfoo@localhost` call that does something other than call cmd_foo, cmd_bar, or erring out.
- Jenda_ 3y ago
  There was another hole if the target command was executed using /bin/bash in a certain way: https://en.wikipedia.org/wiki/Shellshock_(software_bug) https://en.wikipedia.org/wiki/Shellshock_(software_bug) It's probably not the case when the command is the user's shell, but it was exploitable when it was the command= in authorized_keys. Additionally, maybe they are using a custom server because they don't want to fork a new instance of the handler on every login. Here is a stackoverflow topic on limiting the SSH user: https://serverfault.com/questions/152726/how-can-ssh-allowed-to-setup-remote-port-forwarding-but-not-execute-commands https://serverfault.com/questions/152726/how-can-ssh-allowed.... They suggest a few more options, probably not relevant for a gitlab-like use-case. > SSH's default is to not accept the client's environment sshd accepts environment variables specified by AcceptEnv in /etc/ssh/sshd_config. By default, they are mostly related to locales. $ LC_ALL=en_US.UTF8 ssh x date Tue Sep 19 01:14:41 AM UTC 2023 $ LC_ALL=cs_CZ.UTF8 ssh x date Út 19. září 2023, 01:14:46 UTC
  - jolmg 3y ago
    > There was another hole if the target command was executed using /bin/bash in a certain way: https://en.wikipedia.org/wiki/Shellshock_(software_bug) https://en.wikipedia.org/wiki/Shellshock_(software_bug) I agree bash is not the best choice security-wise, but language choice is a bit beside the point with regards to whether or not to bundle a server. > Additionally, maybe they are using a custom server because they don't want to fork a new instance of the handler on every login. That's very valid, though the discussion was about having a reduced attack surface from adding a custom server. > Here is a stackoverflow topic on limiting the SSH user: https://serverfault.com/questions/152726/how-can-ssh-allowed https://serverfault.com/questions/152726/how-can-ssh-allowed.... They suggest a few more options, probably not relevant for a gitlab-like use-case. Thanks for that. > sshd accepts environment variables specified by AcceptEnv in /etc/ssh/sshd_config. By default, they are mostly related to locales. That seems to be a Debian-specific patch. Upstream doesn't include AcceptEnv in the default config file and there seems to be no default value. Your example commands fail to set LC_ALL on my system. `ssh -o SetEnv=LC_ALL=...` also fails.
- garblegarble 3y ago

jolmg 3y ago

EDIT: Crap. You're right. Port forwarding worked... So there's that. `ssh -J userfoo@localhost other-place` also worked... I would imagine that's all able to be disabled, but I see that the user is not fundamentally limited to what the shell allows. That's disappointing. I thought it would wrap everything in `custom-shell.sh -c` calls like it does with the sftp and scp servers. I imagine/hope that under a default configuration one is still not able to touch the contents of the server if the shell doesn't permit it, but being able to use it as a proxy or listen on its ports is not what I expected. ORIG_REPLY: > Don't forget to disable sftp in your sshd_config Doing `strace -fp $(pgrep sshd)` then `sftp userfoo@localhost` in another terminal, I see: $ sftp userfoo@localhost Connection closed. Connection closed $ then in the `strace` output: [pid 408173] execve("/tmp/custom-shell.sh", ["custom-shell.sh", "-c", "/usr/lib/ssh/sftp-server"], 0x55c5f3bae0d0 /* 14 vars */) = 0 [pid 408173] write(1, "/usr/lib/ssh/sftp-server: unknown command\n", 42) = 42 As far as I understand, SSH's security of what a user can do is completely based on what the shell permits the user to do. > are you sure there are no directly/indirectly exploitable bugs/omissions in your script logic for invoking complex commands like git Including a ssh server in the same executable doesn't save you from such bugs. > and that your distributed filesystem works quickly across a few million home folders for your authorized_keys files OpenSSH's sshd seems quite flexible in ways to authenticate users. I don't think having a home folder per user is necessary if you don't want it. > and hopefully there's no sneaky way that an attacker can push an environment variable to break something like with LD_PRELOAD SSH's default is to not accept the client's environment, and this shell itself provides no way to manipulate them. They can be nonexistent in the shell's interface if you don't want them. I put the script so someone can offer some concrete way (as in show me some code) to bypass it in a way that having a custom integrated SSH server would prevent it. I'd love to see a `ssh/sftp userfoo@localhost` call that does something other than call cmd_foo, cmd_bar, or erring out.

Jenda_ 3y ago
There was another hole if the target command was executed using /bin/bash in a certain way: https://en.wikipedia.org/wiki/Shellshock_(software_bug) https://en.wikipedia.org/wiki/Shellshock_(software_bug) It's probably not the case when the command is the user's shell, but it was exploitable when it was the command= in authorized_keys. Additionally, maybe they are using a custom server because they don't want to fork a new instance of the handler on every login. Here is a stackoverflow topic on limiting the SSH user: https://serverfault.com/questions/152726/how-can-ssh-allowed-to-setup-remote-port-forwarding-but-not-execute-commands https://serverfault.com/questions/152726/how-can-ssh-allowed.... They suggest a few more options, probably not relevant for a gitlab-like use-case. > SSH's default is to not accept the client's environment sshd accepts environment variables specified by AcceptEnv in /etc/ssh/sshd_config. By default, they are mostly related to locales. $ LC_ALL=en_US.UTF8 ssh x date Tue Sep 19 01:14:41 AM UTC 2023 $ LC_ALL=cs_CZ.UTF8 ssh x date Út 19. září 2023, 01:14:46 UTC
- jolmg 3y ago
  > There was another hole if the target command was executed using /bin/bash in a certain way: https://en.wikipedia.org/wiki/Shellshock_(software_bug) https://en.wikipedia.org/wiki/Shellshock_(software_bug) I agree bash is not the best choice security-wise, but language choice is a bit beside the point with regards to whether or not to bundle a server. > Additionally, maybe they are using a custom server because they don't want to fork a new instance of the handler on every login. That's very valid, though the discussion was about having a reduced attack surface from adding a custom server. > Here is a stackoverflow topic on limiting the SSH user: https://serverfault.com/questions/152726/how-can-ssh-allowed https://serverfault.com/questions/152726/how-can-ssh-allowed.... They suggest a few more options, probably not relevant for a gitlab-like use-case. Thanks for that. > sshd accepts environment variables specified by AcceptEnv in /etc/ssh/sshd_config. By default, they are mostly related to locales. That seems to be a Debian-specific patch. Upstream doesn't include AcceptEnv in the default config file and there seems to be no default value. Your example commands fail to set LC_ALL on my system. `ssh -o SetEnv=LC_ALL=...` also fails.
garblegarble 3y ago