# Shellshock Question RE: SSH

## sk3l

I don't ~think~ I have many assets that would constitute a viable attack vector for the Shellshock bash bug, but that doesn't mean my understanding is not incomplete or misinformed.

I have a few remote hosts to which I have ssh access. On two of them, I have deployed git repos. For one of the hosts, I control the server and I can gain an unrestricted shell via ssh (after RSA-based authentication). For the other host, it's controlled by a web hosting company, so I can ssh, but with limitations.

Do either of these scenarios sound like they might be vulnerable based on what we know about Shellshock?

My other problem is patching. I have already patched my local machines, which from what I understand is required based on the potential for a malicious DHCP server to burn clients using the vulnerable bash version. For the remote host at the web company, I guess I'll need to rely on them to patch bash. Most unfortunately, for the remote host I control, it's running on an ARM-based NAS server that is using a custom software suite built specifically for that platform, so I'll have to wait for the dev(s) on that platform to push out a fix, which may or may not ever come. This may serve to accelerate my plans to migrate the NAS away from the ARM system to a legit *nix/BSD environment on bigger hardware  :Sad: 

----------

## Hu

As I understand it, this bug allows turning very limited code execution into unrestricted code execution.  If an attacker can cause a bash to run, and can influence the environment fed to that bash, he can execute code of his choosing.  If your ssh server already grants unrestricted shells to everyone who is allowed to authenticate, then I see no way for sshd to be an attack vector, since an attacker could log in normally rather than use the bug.  If your sshd granted restricted shells, such as are used when someone has git access over ssh, but not a general login shell, then that someone could use this bug to run code he is otherwise not allowed to run.  There are other vectors whereby a bash might run as a side effect of an unprivileged remote user interacting with the system.  If in doubt, disallow all interaction with people you would not grant a full shell: no service from Apache, no port-forward-only ssh users, etc.

----------

## sk3l

Thanks Hu, as always. That pretty much aligns with my thinking.

----------

## Ottre

If you use xinetd, check that none of the files in /etc/xinetd.d link to a bash script.

It's pretty common to use a restricted bash shell (a script with #!/bin/bash -r) to provide basic services like IDENT on port 113.

They are now vulnerable to remote attackers.

----------

## Apheus

 *sk3l wrote:*   

> potential for a malicious DHCP server to burn clients using the vulnerable bash version

 

Can someone explain or link details for dhcp? How is shell invocation a part of dhcp communication? Is net-misc/dhcpcd potentially affected?

----------

## sk3l

I think as it relates to DHCP, the vulnerability depends on the behavior of the client. Certain clients can be configured, upon connecting to DHCP servers, to run a bash shell to do things like configure interfaces and run commands, consuming environment variables as part of the process. This is where Shellshock comes in, as a bad DHCP server could include a naughty ENV definition (containing the arbitrary code payload) to deliver to clients.

Here's an example of how this might work.

https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/

----------

## Apheus

Thanks, this answers my questions.

----------

## UberLord

https://plus.google.com/115846119355246858768/posts/1VbQHVZhNtr

 *Quote:*   

> 
> 
> dhcpcd-6.4.6 is hot off the press, the main improvement being mitigating the bash "ShellShock" exploit by escaping all characters as noted in IEEE Std 1003.1, 2004 Edition, 2. Shell Command Language, 2.2 Quoting except for the space character.
> 
> Needless to say, the entire BSD family is not affected by this bug as bash is not the default shell and to be fair a lot of Linux distributions are not affected either. If bash is your Linux distributions /bin/sh, OR you have applications directly calling bash, you should be telling them to get with the times as most people have since moved on to ash, dash or busybox for more efficient processing.
> ...

 

Please note that several prominent systemd developers have taken this opportunity to big up their networkd part with "no bash callouts".

Let me tbe the first to say that dhcpcd does NOT make bash callouts either. It does however make shell callouts where bash could be the default shell - and out of all the default OS's I run (lets say, ohhhh 6 to systemd's 1 - ie linux) bash is only the default on Gentoo? So perversely Gentoo is the one system I have even slightly affected by this; and it's not a server, just a DHCP client.

----------

## sk3l

AFAIK bash is the default shell for more Linux distros than just Gentoo. /bin/sh points to bash on my Arch laptop. This is also the case for my CentOS servers and IIRC for OpenSUSE too.

----------

