4 ms·

I think the point is: how is bundling a custom ssh server into the same executable that interprets the commands, a reduced surface as opposed to using standard

by jolmg 3y ago

I think the point is: how is bundling a custom ssh server into the same executable that interprets the commands, a reduced surface as opposed to using standard openssh's sshd, and defining a simple shell like so: #!/bin/bash cmd_foo() { printf "called foo with %s\n" "$*" } cmd_bar() { printf "called bar with %s\n" "$*" } run_cmd_call() { local cmd="$1"; shift local cmd_args=("$@") case "$cmd" in foo) cmd_foo "${cmd_args[@]}" ;; bar) cmd_bar "${cmd_args[@]}" ;; *) printf "%s: unknown command\n" "$cmd" >&2 esac } while (( $# )); do case "$1" in -c) read -ra cmd_call <<< "$2" shift ;; *) printf "%s: unknown argument\n" "$1" >&2 exit 1 ;; esac shift done if [[ "$cmd_call" ]]; then run_cmd_call "${cmd_call[@]}" else while printf "> " read -ra cmd_call do run_cmd_call "${cmd_call[@]}" done fi (then, of course,) sudo useradd -ms /path/to/custom-shell.sh userfoo sudo -u userfoo bash -c 'mkdir ~/.ssh; printf "%s\n" "$your_pubkey" >> ~/.ssh/authorized_keys' How would you "do more than run one of the commands that it already runs" with this from a `ssh userfoo@localhost` call?

garblegarble 3y ago
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
Too 3y ago
Bash actually has this feature built in. Restricted shell they call it. Start it as rbash or bash -r. It will lock down the shell to not allow cd, setting envvars, launching commands outside working directory and a lot more. If you look at the full list of things they disable you realize how many obscure holes are available you never would have thought about. Not that I would ever trust it enough to expose on a shared box. Likewise with a tailor made shellscript. I’d take a bespoke server in go any day.
- jolmg 3y ago
  It's not the same thing. You're comparing a white-listing approach with a black-listing approach. The example shell doesn't have any concept of directories or environment variables or anything other than cmd_foo and cmd_bar. The only things that exist are the things written to exist.

by jolmg 3y ago

garblegarble 3y ago

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

Too 3y ago

Bash actually has this feature built in. Restricted shell they call it. Start it as rbash or bash -r. It will lock down the shell to not allow cd, setting envvars, launching commands outside working directory and a lot more. If you look at the full list of things they disable you realize how many obscure holes are available you never would have thought about. Not that I would ever trust it enough to expose on a shared box. Likewise with a tailor made shellscript. I’d take a bespoke server in go any day.

jolmg 3y ago
It's not the same thing. You're comparing a white-listing approach with a black-listing approach. The example shell doesn't have any concept of directories or environment variables or anything other than cmd_foo and cmd_bar. The only things that exist are the things written to exist.