<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">You don&#39;t get a /tmp/foo file (I&#39;m testing pre-patch application) and<br></span><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">the env shows only 8 vars, and nothing passed from httpd external input<br></span><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">(like USER_AGENT).</span></blockquote><div><br></div>According to <a href="https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/">https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/</a> PHP run in mod_php mode is safe but some of the methods of running external commands in PHP aren&#39;t if it&#39;s in CGI mode.<div><br></div><div>I just tried something similar on my server, which uses the fpm interface, and the environment isn&#39;t passed.</div><div><br></div><div>Also tried it in a Rails application and it seemed safe. That said, I&#39;ve heard reports that people were able to get some older Rails stuff to work: <a href="https://twitter.com/patio11/status/515097020273401856">https://twitter.com/patio11/status/515097020273401856</a></div><div><br></div><div>Also, for the curious, there are some stories floating around about people sending the exploit in DHCP options.</div><div><br></div><div>Sean</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 26, 2014 at 2:40 AM, Trevor Cordes <span dir="ltr">&lt;<a href="mailto:trevor@tecnopolis.ca" target="_blank">trevor@tecnopolis.ca</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2014-09-25 Gilbert E. Detillieux wrote:<br>
&gt; Didn&#39;t take the script kiddies long to start trying...<br>
<br>
</span>Ya, good catch Sean for speculating on a vector and thanks Gilbert for<br>
giving us an easy check.  I was thinking only along the lines of<br>
attacking ssh/login. Hadn&#39;t thought of http vectors.<br>
<span class=""><br>
&gt; 89.207.135.125 - - [25/Sep/2014:03:22:13 -0500] &quot;GET<br>
&gt; /cgi-sys/defaultwebpage.cgi HTTP/1.0&quot; 404 295 &quot;-&quot; &quot;()<br>
&gt; { :;}; /bin/ping -c 1 198.101.206.138&quot;<br>
&gt; 198.20.69.74 - - [25/Sep/2014:13:49:53 -0500] &quot;GET / HTTP/1.1&quot; 301<br>
&gt; 301 &quot;() { :; }; /bin/ping -c 1 104.131.0.69&quot; &quot;() { :; }; /bin/ping -c<br>
&gt; 1 104.131.0.69&quot;<br>
<br>
</span>I just checked and the exact same hosts tested my server in the same<br>
way.<br>
<span class=""><br>
&gt; I have another host, with some CGI scripts that have names of the<br>
&gt; form */cgi-bin/*.sh, and those URL&#39;s are seeing a lot of attempts<br>
&gt; (all failed as well).  I guess they&#39;ve got lists of potential target<br>
&gt; URL&#39;s to try, and anything ending in &quot;.sh&quot; is going to be<br>
&gt; irresistible!<br>
<br>
</span>For sure someone must have compiled existing web-server lists to<br>
rapidly exploit zero-day http vectors.  I&#39;m actually a bit surprised<br>
that a) they did that and b) my measly SMB site is on the list.<br>
<br>
I run a lot of PHP, and a few fork out calls to perl, almost always via<br>
bash intermediation.  I tested and mod PHP isn&#39;t affected, but I&#39;m<br>
thinking my perl scenario above would be vulnerable, unless PHP is<br>
cleansing the env vars before the bash call.<br>
<br>
A quick test reveals that the above scenario is not vulnerable, it<br>
appears PHP is cleaning the env before exec-type calls:<br>
<br>
Make a php file in your web doc root (say z.php):<br>
&lt;?<br>
$z=`/bin/perl -e &#39;foreach (keys %ENV) { print &quot;\$_\t\$ENV{\$_}\n&quot; } &#39;`;<br>
echo &quot;here are the envs:\n$z\n&quot;;<br>
?&gt;<br>
<br>
644 it and hit it with curl:<br>
<br>
curl -X GET -A &#39;() { :; }; /bin/echo foo&gt;/tmp/foo&#39; <a href="https://foo.bar/z.php" target="_blank">https://foo.bar/z.php</a><br>
<br>
You don&#39;t get a /tmp/foo file (I&#39;m testing pre-patch application) and<br>
the env shows only 8 vars, and nothing passed from httpd external input<br>
(like USER_AGENT).<br>
<br>
Phew!<br>
<br>
Besides CGI which by its nature must pass the ENV, it looks like the<br>
number of http-vector cases may be limited.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Roundtable mailing list<br>
<a href="mailto:Roundtable@muug.mb.ca">Roundtable@muug.mb.ca</a><br>
<a href="http://www.muug.mb.ca/mailman/listinfo/roundtable" target="_blank">http://www.muug.mb.ca/mailman/listinfo/roundtable</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Sean Walberg &lt;<a href="mailto:sean@ertw.com" target="_blank">sean@ertw.com</a>&gt;    <a href="http://ertw.com/" target="_blank">http://ertw.com/</a>
</div>