FYI, the CGI being executed doesn't need to be a bash script. If your webserver runs a CGI via system() or popen() call, both of those execute the command by running bash, ie: bash -c "/path/to/your/binary.cgi".
(Well, technically they usually run "/bin/sh -c", but /bin/sh is often bash.) On Fri, Sep 26, 2014 at 11:59 AM, Doug Hughes <d...@will.to> wrote: > Ned, I think you have under-estimated the severity, perhaps because of > stale information? (just a guess). Here's a good analysis of the bug from > Johannes Ullrich: > https://isc.sans.edu//#__utma=216335632.847683870.1411746865.1411746865.1411746865.1&__utmb=216335632.6.9.1411746895232&__utmc=216335632&__utmx=-&__utmz=216335632.1411746865.1.1.utmcsr=%28direct%29|utmccn=%28direct%29|utmcmd=%28none%29&__utmv=-&__utmk=203629779 > <https://isc.sans.edu//#__utma=216335632.847683870.1411746865.1411746865.1411746865.1&__utmb=216335632.6.9.1411746895232&__utmc=216335632&__utmx=-&__utmz=216335632.1411746865.1.1.utmcsr=%28direct%29%7Cutmccn=%28direct%29%7Cutmcmd=%28none%29&__utmv=-&__utmk=203629779> > > Of note, I believe this sentence of yours is incorrect: " if you can both > manipulate the environment, *and* get bash to execute something else." > > All that is needed is to change the HTTP request headers which are > required by spec to be converted into environment variables. If the CGI in > question is bash, this by itself is sufficient to get it to execute code > that it otherwise should not have. > > I have setup my firewall to block on detection of this attempt. > > > On Fri, Sep 26, 2014 at 7:01 AM, Edward Ned Harvey (lopser) < > lop...@nedharvey.com> wrote: > >> > From: Brandon Allbery [mailto:allber...@gmail.com] >> > >> > I haven't looked to see if Apple's "Web Sharing" involves any CGI >> scripts. If it >> > does, then Web Sharing is vulnerable. >> >> If you have any web server that will execute arbitrary code uploaded by a >> client, that would be vulnerable, but then again, if that's the case, the >> attacker doesn't need the bash bug anymore do they? >> >> The point of this bash bug is that it will execute code it's not supposed >> to execute, if you can both manipulate the environment, *and* get bash to >> execute something else. This vulnerability is not sufficient, all by >> itself, to compromise anybody's system. In order to use it as part of an >> attack, the attacker needs to chain multiple vulnerabilities together. >> >> Unlike heartbleed - which was vulnerable to undetected remote attackers >> having no other knowledge of any vulnerabilities on your system - >> shellshocker can't be exploited remotely without some other bug having >> compromised the system first. >> >> The reason people are calling this "worse than heartbleed" is because (a) >> sensationalism reporting, and (b) the number of systems with bash is higher >> than the number of systems with openssl. But that number alone is >> misleading, because shellshocker is not as easily exploited. >> _______________________________________________ >> Tech mailing list >> Tech@lists.lopsa.org >> https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech >> This list provided by the League of Professional System Administrators >> http://lopsa.org/ >> > > > _______________________________________________ > Tech mailing list > Tech@lists.lopsa.org > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ > >
_______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
