In some cases, depending on the underlying language, it depends on how
the call is structured. e.g. "/usr/local/bin/foo" would be executed
directly by the process, where "/usr/local/bin/foo | bar" used in
exactly the same place, gets executed via popen, calling sh (which is
frequently bash). Got to love consistent behaviour :)
On 09/26/14 13:19, Theo Van Dinter wrote:
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
<mailto: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 <mailto:lop...@nedharvey.com>> wrote:
> From: Brandon Allbery [mailto:allber...@gmail.com
<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 <mailto: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 <mailto: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/