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/

Reply via email to