[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Sep 2014 08:21:58 -0700
From: Michal Zalewski <lcamtuf@...edump.cx>
To: oss-security@...ts.openwall.com
Cc: Chester Ramey <chet.ramey@...e.edu>
Subject: Re: CVE-2014-6271: remote code execution through bash
> There seems to be a wider issue even when we have well-formed functions
> coming in, for example,
>
> env rm='() { echo will not; }' bash -c 'rm core'
Sure. This is less of an immediate concern because in the scenarios we
are most worried about, the attacker usually doesn't have the ability
to set arbitrary variables (and if he could, it would be a problem
greater than anything that bash could deal with - LD_PRELOAD and all).
It is, however, customary to be able to set the *values* of variables
whose names are constrained in some way - most notably, HTTP_*.
FWIW, I tried to sum up the exposure and our thoughts on the patches here:
http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-bug-its-impact.html
/mz
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
