3 ms·

> this vulnerability might permit code execution with the privileges of the authenticated user Yet another vote for secure authentication, which typically mean

by j_s 13y ago

> this vulnerability might permit code execution with the privileges of the authenticated user Yet another vote for secure authentication, which typically means requiring use of a private key and disabling root login.

0x0 13y ago
Not sure what you're thinking about here, since the vulnerability is post-authentication? A bug like this could be pretty devastating for github and bitbucket type setups where everyone in the world is using a shared, restricted "git" UNIX user authenticating with a private key, for git ssh push and pull.
- simgidacav 13y ago
  This bug is problematic for all those situations where the ssh protocol is not used for telnet-style command line, but as a transport. e.g. Git uses ssh as transport protocol, but github (and similar platforms) don't support direct user login.
  - johnchristopher 13y ago
    What about git-shell over ssh ?
  - simgidacav 13y ago
    > What about git-shell over ssh ? I guess that gives the same problem. The exploitation allows to execute arbitrary code, as you would do by launching commands from, say, bash. I don't know git-shell, but I guess (from the manpage) it restricts the allowed commands. The exploitation of the bug would allow a malicious user to execute a command instead of git-shell. A good example of command could be /bin/bash.
- j_s 13y ago
  Hopefully this clears it up for you: https://news.ycombinator.com/item?id=6696070 https://news.ycombinator.com/item?id=6696070
zokier 13y ago
I'd rather put this as a vote for proper os level privilege management/access control. You shouldn't need to trust OpenSSH to limit user privileges.
dzhiurgis 13y ago
Perhaps you have got a good guide how to implement this?
- spindritf 13y ago
  Doesn't help in this case but in your /etc/ssh/sshd_config or similar change or, if missing, add PubkeyAuthentication yes ChallengeResponseAuthentication no PasswordAuthentication no PermitRootLogin no Make sure you can log in using your key and su/sudo from that unprivileged user before applying those changes.
  - dzhiurgis 13y ago
    Thanks, done that.
- antocv 13y ago
  Just google it, its in the manual as well. But the gist of it is PermitRootLogin no in your sshd_config and Protocol 2 (to disable protocol 1), PubkeyAuthentication yes Password authentication no For this specific vulnerability those will not do, as this exploit is for post-authentication, whether password or pubkey doesnt matter. Hence, you can add Ciphers blowfish-cbc which will only allow that cipher to be used. Also add MACs hmac-sha2-512 to only allow that MAC and none, weaker, others.
djmdjm 13y ago
The authentication method used is completely orthogonal to this bug.
- j_s 13y ago
  > completely orthogonal I was explaining the benefits of layers of security. This issue is an issue only to the degree that your server does not trust authenticated users, because it can only be exploited by authenticated users. The main thing I wanted to see when I saw the OP was 'do I need to update SSH on my personal server yesterday'... and I'm not worried about it at this point.

by j_s 13y ago

0x0 13y ago

Not sure what you're thinking about here, since the vulnerability is post-authentication? A bug like this could be pretty devastating for github and bitbucket type setups where everyone in the world is using a shared, restricted "git" UNIX user authenticating with a private key, for git ssh push and pull.

simgidacav 13y ago
This bug is problematic for all those situations where the ssh protocol is not used for telnet-style command line, but as a transport. e.g. Git uses ssh as transport protocol, but github (and similar platforms) don't support direct user login.
- johnchristopher 13y ago
  What about git-shell over ssh ?
- simgidacav 13y ago
  > What about git-shell over ssh ? I guess that gives the same problem. The exploitation allows to execute arbitrary code, as you would do by launching commands from, say, bash. I don't know git-shell, but I guess (from the manpage) it restricts the allowed commands. The exploitation of the bug would allow a malicious user to execute a command instead of git-shell. A good example of command could be /bin/bash.
j_s 13y ago
Hopefully this clears it up for you: https://news.ycombinator.com/item?id=6696070 https://news.ycombinator.com/item?id=6696070

zokier 13y ago

I'd rather put this as a vote for proper os level privilege management/access control. You shouldn't need to trust OpenSSH to limit user privileges.

dzhiurgis 13y ago

Perhaps you have got a good guide how to implement this?

spindritf 13y ago
Doesn't help in this case but in your /etc/ssh/sshd_config or similar change or, if missing, add PubkeyAuthentication yes ChallengeResponseAuthentication no PasswordAuthentication no PermitRootLogin no Make sure you can log in using your key and su/sudo from that unprivileged user before applying those changes.
- dzhiurgis 13y ago
  Thanks, done that.
antocv 13y ago
Just google it, its in the manual as well. But the gist of it is PermitRootLogin no in your sshd_config and Protocol 2 (to disable protocol 1), PubkeyAuthentication yes Password authentication no For this specific vulnerability those will not do, as this exploit is for post-authentication, whether password or pubkey doesnt matter. Hence, you can add Ciphers blowfish-cbc which will only allow that cipher to be used. Also add MACs hmac-sha2-512 to only allow that MAC and none, weaker, others.

djmdjm 13y ago

The authentication method used is completely orthogonal to this bug.

j_s 13y ago
> completely orthogonal I was explaining the benefits of layers of security. This issue is an issue only to the degree that your server does not trust authenticated users, because it can only be exploited by authenticated users. The main thing I wanted to see when I saw the OP was 'do I need to update SSH on my personal server yesterday'... and I'm not worried about it at this point.