[GRLUG] CVE-2014-6271

Kevin McCarthy signals42 at gmail.com
Thu Sep 25 13:27:05 EDT 2014


BTW, It looks like I'll be patching it again on the RHEL systems:

https://access.redhat.com/security/cve/CVE-2014-7169

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.

-Kevin

On Thu, Sep 25, 2014 at 1:19 PM, Kevin McCarthy <signals42 at gmail.com> wrote:

> If an attacker has remote control of environment variables think of the
>> damage that can be done with LD_LIBRARY_PATH.
>>
>
> 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.
>
> 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.
>>
>
> 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.
>
> 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.
>
>
>
> On Thu, Sep 25, 2014 at 10:37 AM, Mark Farver <mfarver at mindbent.org>
> wrote:
>
>> 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.
>>
>> Many applications have buffer overflows in environment handling.  Remote
>> code execution or denial of service.
>>
>> 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.
>>
>> Mark
>> On Sep 25, 2014 8:55 AM, "Michael Mol" <mikemol at gmail.com> wrote:
>>
>>> On Thu, Sep 25, 2014 at 8:16 AM, Adam Tauno Williams
>>> <awilliam at whitemice.org> wrote:
>>> > On Wed, 2014-09-24 at 15:08 -0400, Mark Farver wrote:
>>> >> I think it is a stretch to label this remotely exploitable.
>>> >
>>> > Ditto.  This is a theoretical exploit of a system that has issues.
>>>
>>> I'd like to hear your explanation of this. Why would a system have to
>>> have "issues" for this to be exploitable? (Outside of the obvious that
>>> it's running a vulnerable version of bash.)
>>>
>>> --
>>> :wq
>>> _______________________________________________
>>> grlug mailing list
>>> grlug at grlug.org
>>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>>>
>>
>> _______________________________________________
>> grlug mailing list
>> grlug at grlug.org
>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20140925/75bfd077/attachment-0001.html>


More information about the grlug mailing list