bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issues with exported functions


From: Chet Ramey
Subject: Re: Issues with exported functions
Date: Wed, 24 Sep 2014 16:29:36 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 9/24/14, 4:07 PM, Greg Wooledge wrote:
> On Thu, Sep 25, 2014 at 03:54:19AM +0800, lolilolicon wrote:
>> I think almost as severe as CVE-2014-6271 is that it's still possible to
>> mask commands in a bash script by changing it's environment.
>>
>> For example, true='() { false;}' or grep='() { /bin/id;}' ...
> 
> I'm still waiting for someone to successfully exploit this and post
> it to Chet.  Or maybe someone already did, and it's being kept quiet.

Not really.  This has always been possible: bash searches the shell
function space before $PATH and exported functions still work, so you
don't need to futz around with variables.

You can simply export a function named `grep', the child shell will
find it, and it will use it.  This is one of the reasons that setuid
shells and restricted shells don't import shell functions.

You can usually achieve the same effect by putting a script named grep
in a private bin directory and arranging that that directory appear before
/bin in your $PATH.  This, however, can be defeated by shell scripts that
set their own value of $PATH or use full pathnames to commands.

You can cause misbehavior using this, but it will only affect you.
This is not a privilege escalation vulnerability.  The danger is how
it can be exploited remotely.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]