[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    =?utf-8?B?UmU6IFtvc3Mtc2VjdXJpdHldIFJlOiBDVkUtMjAxNC02MjcxOiByZW1vdGUgY29k?= =?utf-8?B?ZSBleGVjdXRpb
From:       "=?utf-8?B?TWFyayBSIEJhbm5pc3Rlcg==?=" <mark () proseconsulting ! co ! uk>
Date:       2014-09-26 12:41:45
[Download RAW message or body]

[Attachment #2 (text/plain)]

Arguments that people shouldn't have setuid shell scripts don't stack up, because even if you \
write your setuid program in some other language, you might unwittingly exec something written \
in bash. As /bin/sh is symlinked to /bin/bash in RHEL, the moment you call out to the system to \
do a piece of work for you, you're at risk of invoking bash and thereby being vulnerable to a \
root exploit.  For example:

$ env bzip2='() { echo vulnerable >&2; }' /usr/bin/bzdiff /tmp/file1.bz /tmp/file2.bz

$ env test='() { echo vulnerable >&2; }' /usr/bin/ldd /usr/bin/gcc

So this is not about whether or not someone has written a setuid shell script.  This has \
uncovered a potential new exploit for any setuid program.  Indeed the very first setuid program \
that I discovered this exploit with was a binary (compiled C program) that happened to exec ldd \
while it was running.

I don't think this issue can be swept under the carpet.



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic