<div dir="ltr"><div>BTW, It looks like I'll be patching it again on the RHEL systems:<br><br><a href="https://access.redhat.com/security/cve/CVE-2014-7169">https://access.redhat.com/security/cve/CVE-2014-7169</a><br><br></div><div>The quick-fix from yesterday didn't completely deal with the issue, so you should probably check with your vendors and see if you need to apply another one today. Thank goodness for Satellite/Spacewalk.<br><br></div><div>-Kevin<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 25, 2014 at 1:19 PM, Kevin McCarthy <span dir="ltr"><<a href="mailto:signals42@gmail.com" target="_blank">signals42@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">If an attacker has remote control of environment variables think of the damage that can be done with LD_LIBRARY_PATH. <br></blockquote><div><br></div></span><div>The issue here is that it can be expolited through ANY environment variable. So, the env variables that pass things to CGI are vulnerable. You can exploit it with a variable called X. TERM even works.<br><br></div><span class=""><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>This exploit seems to be about bash specifically, and specifically about ways to set environment variables. But really, I just don't want set-an-environment-variable to ever happen.<br></div></blockquote><div><br></div></span><div>I agree, I don't WANT it to happen either. But, what I want, and what actually happens within my organization are two completely different things. I've got several pieces of commercial off-the-shelf software running on multiple servers that make use of CGI scripts. I don't have the ability to tell my customers that they can't have that software anymore, and I don't have the resources (or legal right in many cases) to modify it to do something saner than CGI. Best practice != real environment.<br><br></div><div>But, whatever... It's probably a big issue for most enterprises; the information is out there, so patch if you think it important enough... Or don't.<br></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 25, 2014 at 10:37 AM, Mark Farver <span dir="ltr"><<a href="mailto:mfarver@mindbent.org" target="_blank">mfarver@mindbent.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">If an attacker has remote control of environment variables think of the damage that can be done with LD_LIBRARY_PATH. Upload a file to a harmless path on webserver and use the library path to link it into an executable running in a CGI env. Instant remote code execution.</p>
<p dir="ltr">Many applications have buffer overflows in environment handling. Remote code execution or denial of service.</p>
<p dir="ltr">Basically environment variables are not terribly secure and have not received a lot of security analysis. If you let an attacker control them for a process running as another user there are probably vectors there. <br><span><font color="#888888"><br></font></span></p><span><font color="#888888">
<p dir="ltr">Mark </p></font></span><div><div>
<div class="gmail_quote">On Sep 25, 2014 8:55 AM, "Michael Mol" <<a href="mailto:mikemol@gmail.com" target="_blank">mikemol@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Sep 25, 2014 at 8:16 AM, Adam Tauno Williams<br>
<<a href="mailto:awilliam@whitemice.org" target="_blank">awilliam@whitemice.org</a>> wrote:<br>
> On Wed, 2014-09-24 at 15:08 -0400, Mark Farver wrote:<br>
>> I think it is a stretch to label this remotely exploitable.<br>
><br>
> Ditto. This is a theoretical exploit of a system that has issues.<br>
<br>
I'd like to hear your explanation of this. Why would a system have to<br>
have "issues" for this to be exploitable? (Outside of the obvious that<br>
it's running a vulnerable version of bash.)<br>
<br>
--<br>
:wq<br>
_______________________________________________<br>
grlug mailing list<br>
<a href="mailto:grlug@grlug.org" target="_blank">grlug@grlug.org</a><br>
<a href="http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug" target="_blank">http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
grlug mailing list<br>
<a href="mailto:grlug@grlug.org" target="_blank">grlug@grlug.org</a><br>
<a href="http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug" target="_blank">http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug</a><br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>