"Shell Shock", the bash complement to heartbleed (AS IF)
-
OK, it's less of a WTF than I thought... but it's still a WTF that they apparently fixed it properly on Ubuntu 10.04 and 12.04, but not 14.04.
-
Did "they" actually fix anything? Didn't they just accept upstream patches? I presume there are different versions of bash among the 10/12/14 editions.
-
Theoretically shellshock is a big deal, but attack vectors are so specific and unlikely, it's not a matter of great urgency.
I think it's pretty common to have a ten-year-old Perl script in cgi-bin that needlessly shells out for
grepor something...These kinds of things are always about all the holes in the swiss cheese lining up.
Although in computing, it's usually just a single hole that needs to line up with itself for disasters to happen.
-
If Perl is shelling out for grep, the developer is Doing It Wrong™. @CodingHorrorBot
I mean, there's a reason they're called Perl-Compatible Regular Expressions in PHP and the like....
-
@powerlord Is Doing It Wrong™<t3436p54>
-
If Perl is shelling out for grep, the developer is Doing It Wrong™.
Right but that doesn't make the code magically disappear.
-
@powerlord Is Doing It Wrong™<t3436p54>
-
Is @CodingHorrorBot doing it wrong by replying twice?
-
@jaloopa Is Doing It Wrong™<t3436p58>
-
Is @CodingHorrorBot doing it wrong by replying twice?
I would think so.
(Darn, it seems I did not summon the bot.)
-
The site hiccuped, so no telling if it was the bot or the site that did it.
-
Poor timing - the site seemed to hiccup as the bot tried to mark the notification read, which failed, so when it restarted it picked the notification up again.
-
I created an account just to like it
-
I'm seeing various outlets claim this affects routers and such, but I don't think so. Those devices do run linux, but typically have /bin/sh linked to busybox, and don't run bash at all.
-
I'm seeing various outlets claim this affects routers and such, but I don't think so. Those devices do run linux, but typically have /bin/sh linked to busybox, and don't run bash at all.
The problem isn't necessarily that it will affect all of them, the problem is that nobody has a good sense for how many are vulnerable. At this point, nobody knows how big the fix is going to be.
-
Third variation of ShellShock identified. So expect yet another patch.
-
That's the basic feature. It was mentioned in the initial emails already. I believe they're planning to harden it in some way, which would make it easy for calling programs to remove all functions from the environment.
-
nobody has a good sense for how many are vulnerable
I've seen a lot of Linux-based consumer-grade routers and modems. Never seen one shipped with bash installed. All busybox. My sense is that the number of consumer-grade routers and modems affected by this bug is very very small.
-
Ok? You win forumpointzzz? I guess?
-
-
Ok? You win forumpointzzz? I guess?
What were you attempting to tell the world with this post? Do you think you succeeded?
-
He was probably looking for a "dickweedery, non-pedantic" badge, not realizing he's already got one:
-
http://seclists.org/oss-sec/2014/q3/741
Third variation of ShellShock identified. So expect yet another patch.
Bullshit, this isn't a vulnerability. If a setuid/setgid preserves the environment, that is the vulnerability. Otherwise there are countless more vulnerabilities available: say, simply updating PATH, or LD_LIBRARY_PATH, and there's even some environment variable that is executed before running bash, though I forgot its name (something to do with setting which rc file to execute I think - maybe INPUTRC).
Being able to set environment variables is equal to owning the machine. There's nothing new about that. Just some dude trying to win some fame here, I imagine...
So no, don't expect yet another patch.
-
Missed at least these kind of attacks...
https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
-
OS X's sh is bash.
The executables seem to be different, though (this on OS X 10.9.5):
[code]$ diff /bin/sh /bin/bash
Binary files /bin/sh and /bin/bash differ
$ ls -l /bin/bash /bin/sh
-r-xr-xr-x 1 root wheel 1228240 7 dec 2013 /bin/bash
-r-xr-xr-x 1 root wheel 1228304 7 dec 2013 /bin/sh[/code]Edit: Why is the quote broken?
-
I checked on OS X 10.6 and the executables were both the same size and timestamp. And both bash.
Anyway, I'm not aware of any other shell whose binary would be more than a megabyte. Even zsh isn't much over half a megabyte.
-
Missed at least these kind of attacks...
https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
Yeah, I found https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ yesterday. It gives a very good overview of possible attacks, including one launched from a (rogue) DHCP server. But I think they're still mitigated by having a non-bash
/bin/sh. (The '1000% worse' I mentioned was not an exaggeration.)
-
I checked on OS X 10.6 and the executables were both the same size and timestamp. And both bash.
I have to add that the difference of a grand total of 64 bytes between sh and bash isn’t really enough to convince me that the two aren’t basically the same. And if they are, why isn’t one just symlinked to the other as many Linuxes seem to do? Maybe the difference is explained by this:
[code]$ sh
sh-3.2$ exit
$ bash
bash-3.2$ [/code]
Or no, wait, the thing just displays whatever command was given to start the shell, as I discovered when I symlinked “test” to /bin/bash and ran ./test. It makes even less sense to have two different files in that light.I'm not aware of any other shell whose binary would be more than a megabyte.
[code]$ls -l /bin/*sh
-r-xr-xr-x 1 root wheel 1228240 7 dec 2013 /bin/bash
-rwxr-xr-x 2 root wheel 357984 7 dec 2013 /bin/csh
-r-xr-xr-x 1 root wheel 1315248 7 dec 2013 /bin/ksh
-r-xr-xr-x 1 root wheel 1228304 7 dec 2013 /bin/sh
-rwxr-xr-x 2 root wheel 357984 7 dec 2013 /bin/tcsh
-rwxr-xr-x 1 root wheel 530320 7 dec 2013 /bin/zsh[/code]
ksh is bigger than bash, even, while csh and tcsh seem to be hard links for the same executable.
-
ksh is bigger than bash, even, while csh and tcsh seem to be hard links for the same executable.
Eh, my ksh is only 420 KB. Must be a different version.
-
Nope. Those don't exist. SpoofedEx said expect no more patches. He is Mr. Expert Man.
-
if you invoke system calls from e.g. Perl the shell is invoked.
You're Doing It Wrong™ if the shell is involved.
You should be using 3-arg open(), 3/4-arg sysopen()4-arg for create/write or mult-arg system()calls always:
# perl will *bypass* the shell in all these cases: use Fcntl qw(:DEFAULT :flock); my $file_name = "c:/users/dada/my documents/input.txt"; my $program_to_run = "c:/path/to/file/to/execute"; my @args_for_program = ( "arg1", "arg2", "arg3", … ); open( my $fh, "<", $file_name ) or die "cannot open $file_name: $!"; sysopen( my $fh, $file_name, O_RDONLY ) or die "cannot open $file_name: $!"; system( $program_to_run, @args_for_program ) == 0 or die "cannot run $program_to_run, @args_for_program: $!";And if you're running a CGI (sic) program you should be using taint mode in perl ( IIS/Win32 info here and here | general perlsec info here )
-
-
a very good overview of possible attacks, including one launched from a (rogue) DHCP server. But I think they're still mitigated by having a non-bash /bin/sh.
I've just been playing with this on a Debian Jessie box with bash 4.3.11(1) and dhclient 4.3.0. I can't make anything bad happen via DHCP, but I don't think that has anything to do with the fact that sh is dash, not bash, on this box.I configured my DHCP server to send a hostname of
() { :;}; touch /tmp/pwnedand used Wireshark to verify that (a) the DHCP Discover and DHCP Request packets do include parameter lists requesting the Hostname option and (b) the bogus hostname above does appear on the wire in the DHCP ACK. However, /tmp/pwned does not get created after using dhclient.This can't have anything to do with what /bin/sh is linked to on this box, since /sbin/dhclient-script has an explicit #!/bin/bash shebang line (not sure why- a cursory reading reveals no obvious bashisms).
After adding the following fragment to the start of /sbin/dhclient-script
{ printf '%q ' "$0" "$@" echo set echo ---- } >>/tmp/dhclient-script.logand invoking
dhclient eth0, I see logging from an invocation of dhclient-script that shows no exported functions:
No sign of a
/sbin/dhclient-script
BASH=/bin/bash
BASHOPTS=cmdhist:complete_fullquote:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
BASH_ALIASES=()
BASH_ARGC=()
BASH_ARGV=()
BASH_CMDS=()
BASH_LINENO=([0]="0")
BASH_SOURCE=([0]="/sbin/dhclient-script")
BASH_VERSINFO=([0]="4" [1]="3" [2]="11" [3]="1" [4]="release" [5]="x86_64-pc-linux-gnu")
BASH_VERSION='4.3.11(1)-release'
DIRSTACK=()
EUID=0
GROUPS=()
HOSTNAME=jellyshot
HOSTTYPE=x86_64
IFS=$' \t\n'
MACHTYPE=x86_64-pc-linux-gnu
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/usr/sbin:/sbin:/bin:/usr/sbin:/usr/bin
PIPESTATUS=([0]="0")
PPID=21513
PS4='+ '
PWD=/root
SHELL=/bin/bash
SHELLOPTS=braceexpand:hashall:interactive-comments
SHLVL=1
TERM=dumb
UID=0
_=echo
interface=eth0
new_broadcast_address=192.168.119.255
new_dhcp_lease_time=86400
new_dhcp_message_type=5
new_dhcp_rebinding_time=75600
new_dhcp_renewal_time=43200
new_dhcp_server_identifier=192.168.119.254
new_domain_name=redacted.lan
new_domain_name_servers=192.168.119.254
new_expiry=1412003779
new_ip_address=192.168.119.2
new_network_number=192.168.119.0
new_ntp_servers=192.168.119.254
new_routers=192.168.119.254
new_subnet_mask=255.255.255.0
old_broadcast_address=192.168.119.255
old_dhcp_lease_time=86400
old_dhcp_message_type=5
old_dhcp_rebinding_time=75600
old_dhcp_renewal_time=43200
old_dhcp_server_identifier=192.168.119.254
old_domain_name=redacted.lan
old_domain_name_servers=192.168.119.254
old_expiry=1411917377
old_ip_address=192.168.119.2
old_network_number=192.168.119.0
old_ntp_servers=192.168.119.254
old_routers=192.168.119.254
old_subnet_mask=255.255.255.0
pid=21513
reason=BOUND
requested_broadcast_address=1
requested_domain_name=1
requested_domain_name_servers=1
requested_domain_search=1
requested_host_name=1
requested_interface_mtu=1
requested_netbios_name_servers=1
requested_netbios_scope=1
requested_ntp_servers=1
requested_rfc3442_classless_static_routes=1
requested_routers=1
requested_subnet_mask=1
requested_time_offset=1new_host_nameenvironment variable either. So it seems that dhclient itself is doing some sanity checks on what goes in the environment passed to dhclient-script.
-
TIL some nerd at some point grew bored and wrote their own "lightweight" bash replacement for debian.
It was not written for Debian. It existed long ago already under name
ash. Some distributions still ship it (e.g. Cygwin; unfortunately Cygwin does not allow using it for/bin/sh, at least not easily). I used it since around 2000 when a friend told me thatlarch(the older shell+tar+patch-based incarnation of GNU Arch) worked significantly faster with it. Not long after that Debian folks found it made system scripts like the startup ones run a lot faster too and started pushing the switch of/bin/shto it. Meanwhile the original maintainer went missing in action, so the Debian maintainer forked it and renamed it todash.
-
Cool story, bro.
-
It was not written for Debian. It existed long ago already under name ash.
And it was never a replacement for bash; it was a replacement for the at-the-time-proprietary Bourne Shell.
-
No, they're not mitigated. Take a look at isc dhcp client:
$ head -n 1 /sbin/dhclient-script #!/bin/bash
-
-
Most Linux-based boxes configured to acquire an IP address via DHCP do.
/sbin/dhclient does the actual packet exchange with whatever DHCP server it finds on the LAN, then makes some of the DHCP options supplied by that server available to /sbin/dhclient-script in environment variables. It does this to let /sbin/dhclient-script handle scripty stuff like messing with name resolvers and NTP clients and assorted other things that DHCP can provide parameters for.
/sbin/dhclient-script is, as eis points out, a bash script, and it generally runs as root - making it a very juicy target for major pwnage via a malicious DHCP server. And DHCP is a broadcast-based protocol with no inbuilt security at all, so it's trivial to stick a malicious one on any LAN and make it hand out Bad Things in DHCP options.
Mitigating that are two facts: first, /sbin/dhclient completely ignores all DHCP server options it didn't ask for in its initial DHCP request; second, it does seem to do some basic sanity checks. I have yet to find a way to persuade it to hand anything shell-shocky along to /sbin/dhclient-script.
I would be very interested to find out whether anybody has actually managed to pwn a box running the isc dhcp client and a vulnerable version of bash. As far as I know, it's still only a theoretical risk at this stage.
-
It seems that dhcpcd does less effective sanity checking than ISC dhclient. If I were running the former, I'd be concerned right now.
oss-sec: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability)
