<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 26, 2014 at 1:20 PM, Russell Coker <span dir="ltr">&lt;<a href="mailto:russell@coker.com.au" target="_blank">russell@coker.com.au</a>&gt;</span> wrote:<br><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 class="">On Fri, 26 Sep 2014, Ian &lt;<a href="mailto:ilox11@gmail.com">ilox11@gmail.com</a>&gt; wrote:<br>
&gt; The journos are having a field day over the discovery of the<br>
&gt; vulnerabilities in Bash, the vulnerability now called Shellshock. They talk<br>
&gt; of 500million affected sites. Any Apache server is easily taken over. Some<br>
&gt; reporting that the patches not fully safe yet.<br>
<br>
</span>wget -U &quot;() { test;};/usr/bin/touch /tmp/VULNERABLE&quot; \<br>
<a href="http://www.example.com/cgi-bin/whatever" target="_blank">http://www.example.com/cgi-bin/whatever</a><br>
<br>
Above is a test for a vulnerable cgi-bin script courtesy of<br>
<a href="https://twitter.com/hernano" target="_blank">https://twitter.com/hernano</a> .<br>
<br>
ssh root@localhost &quot;() { :;} ; touch /tmp/ohno&quot;<br>
<br>
Above is a test I wrote for ssh where ~root/.ssh/authorized_keys allows access<br>
but with the &quot;command=&quot; option (which sets the original command to the<br>
SSH_ORIGINAL_COMMAND variable).  Note that this doesn&#39;t do anything useful in<br>
the case where unrestricted ssh access is granted.<br>
<br>
If you have bash cgi-bin scripts then an attacker can run arbitrary code as<br>
www-data.</blockquote><div><br></div><div>*nit-pick* The CGI scripts don&#39;t have to be written in bash; anything that invokes bash is vulnerable. <br><br>The RedHat blog post (<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>)  lists a few routes to this: CGI scripts written in C which call system() or popen(), os.system() or os.popen() in Python, system() or exec() in PHP, and open() or system() in Perl (the PHP and Perl examples have other caveats as those languages don&#39;t always call bash)</div><div><br></div><div>So it&#39;s quite possible that you have a CGI script written in C that uses system() to call curl, or a Perl script that invokes ImageMagick</div><div><br></div><div>It&#39;s not just Apache and SSH that are potential vectors: anything that listens on the network could be a vector, if it invokes bash and passes data into the environment. SSH and Apache were obvious problems and found quickly, but Robert Graham&#39;s post about this also warns that he&#39;s found vulnerable DHCP clients (<a href="https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/">https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/</a> shows one example of a DHCP client executing arbitrary code supplied by the DHCP server)</div><div><br></div><div><br></div><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">  As long as you don&#39;t run such scripts as root that isn&#39;t<br>
necessarily a huge problem (depending on what your scripts do and how<br>
important the web server is to you).  For example if you have a web server<br>
that mostly serves static data and doesn&#39;t have write access to that data then<br>
the ability of an attacker to mess with you will be limited.<br>
<br>
If you use ssh as a sudo replacement for root access then you have a more<br>
serious problem.<br>
<br>
If you have a cgi-bin script written in bash that then runs a program as root<br>
via the ssh command= option then it&#39;s a remote root exploit.<br>
<span class=""><br>
&gt; Should there be a focus within the Linux world to track down all the little<br>
&gt; bits that make up the foundation of the software and making sure they are<br>
&gt; being maintained and secure and above all trusted? Perhaps LA or the next<br>
&gt; LCA could/should pick this up as a theme and be a leader in the open source<br>
&gt; world?<br>
<br>
</span>Yes.  Also we should make all things be secure by default.  If we don&#39;t have<br>
daemons running scripts in a default configuration then as most users stick to<br>
the defaults for most things that will make most systems secure.<br>
<br>
Finally running things with minimum privileges is a good thing.  SE Linux is<br>
good for this.<br>
<span class=""><font color="#888888"><br>
--<br>
My Main Blog         <a href="http://etbe.coker.com.au/" target="_blank">http://etbe.coker.com.au/</a><br>
My Documents Blog    <a href="http://doc.coker.com.au/" target="_blank">http://doc.coker.com.au/</a><br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
linux-aus mailing list<br>
<a href="mailto:linux-aus@lists.linux.org.au">linux-aus@lists.linux.org.au</a><br>
<a href="http://lists.linux.org.au/listinfo/linux-aus" target="_blank">http://lists.linux.org.au/listinfo/linux-aus</a><br>
</div></div></blockquote></div><br></div></div>