3 ms·
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.w
by 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.