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

[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]

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-20 ... f-concept/

[Apheus]

Thanks, this answers my questions.

[UberLord]

https://plus.google.com/115846119355246 ... VbQHVZhNtr

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.

Regardless, shell is such an important in part of the system - it allows non programmers to "do things". Thanks to the dhcpcd hook system, a user was able to start tcpdump on hotplugged interface before dhcpcd actually started using it during the boot process. Why he wanted to do this, I don't know, probably for some debugging. But the point is, how would he have done this without shell hooks?

The important thing to take away from this is don't lock yourself into one technology - strive to be portable. dhcpcd works on many OS's, libcs, shells and userland tools. If any of them prove faulty, swap them out - including dhcpcd itself! But please at least tell me why you're swapping dhcpcd out so I can improve it

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.