Path: csiph.com!au2pb.net!feeder.erje.net!2.us.feeder.erje.net!news.glorb.com!usenet.stanford.edu!not-for-mail From: Chet Ramey Newsgroups: gnu.bash.bug Subject: Re: SHELLOPTS=xtrace security hardening Date: Sun, 13 Dec 2015 12:49:58 -0500 Organization: ITS, Case Western Reserve University Lines: 30 Approved: bug-bash@gnu.org Message-ID: References: <20151210201649.126444eionzfsam8@webmail.alunos.dcc.fc.up.pt> Reply-To: chet.ramey@case.edu NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1450029011 4673 208.118.235.17 (13 Dec 2015 17:50:11 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bug-bash@gnu.org, chet.ramey@case.edu To: up201407890@alunos.dcc.fc.up.pt Envelope-to: bug-bash@gnu.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <20151210201649.126444eionzfsam8@webmail.alunos.dcc.fc.up.pt> X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.566DAFC8.000F,ss=1,re=0.000,fgs=0, ip=198.14.219.209, so=2015-08-12 04:07:17, dmn=2011-05-27 18:58:46 X-Mirapoint-Loop-Id: c14718c15c1362e72f4c9e4d2da1539e X-Junkmail-Whitelist: YES (by domain whitelist at mpv3-2015.case.edu) X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.566DAFC8.0078,ss=1,re=0.000,fgs=0, ip=198.14.219.209, so=2015-08-12 04:07:17, dmn=2011-05-27 18:58:46 X-Mirapoint-Loop-Id: 3683e406f74ec035c928cf713ddf0d3e X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 129.22.103.194 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:12000 On 12/10/15 2:16 PM, up201407890@alunos.dcc.fc.up.pt wrote: > Hello, > > This is a suggestion for a bash security hardening patch which prevents > xtrace from being initialized to the SHELLOPTS environment variable when a > new shell starts. This is far too drastic a solution to the problem you have posed. > xtrace can be used to exploit bogus system()/popen() calls on setuid > binaries via a specially crafted PS4 environment variable leading to > privilege escalation, like so: I don't really see privilege escalation here. Your setuid root program sets the real and effective UIDs to 0 and calls system(). There is no way to distinguish this as the result of running a setuid program, and any privilege escalation takes place before system() runs. I have to tell you, if I wanted to exploit a program written this poorly, I wouldn't mess around with SHELLOPTS. I'd go straight to PATH. This isn't a good reason to take xtrace out of $SHELLOPTS unconditionally. It's not even a good enough reason to ignore SHELLOPTS if the shell is running as uid 0. -- ``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/