[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