Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <542AC920.3080600@debian.org>
Date: Tue, 30 Sep 2014 16:15:44 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: Healing the bash fork

On 30/09/14 15:27, Michal Zalewski wrote:
>> Florian's prefix/suffix patch is not going to protect against the
>> setuid/setgid exploit that I reported to this list last week.
...
>> http://technicalprose.blogspot.co.uk/2014/09/shellshock-bug-third-vulnerability.html
>
> You do realize that your setuid program is patently unsafe, right?
> Say:
> 
> $ echo -e '#!/bin/sh\necho pwn3d' >date;chmod 755 date;PATH=.:$PWD 
> ./setuid_program
> pwn3d

Other ways to attack this "simple, easy and wrong" setuid program
include LD_PRELOAD and, depending on implementation details, any of:

LD_LIBRARY_PATH (if sh(1) and/or date(1) is dynamically-linked)
ENV (if sh(1) is ksh, at least according to sudo source code)
BASH_ENV (if sh(1) is bash)
PYTHONPATH (if you replace date(1) with any Python script)
PERL5LIB (if you replace date(1) with any Perl script)
DBUS_SESSION_BUS_ADDRESS (if you replace date(1) with something that
uses D-Bus)
...

and that's without getting into odd corners of Unix which are not
directly executed, but can be used to construct a more subtle
vulnerability (e.g. IFS).

Several of these are "disarmed" if ruid != euid (e.g. D-Bus, to address
CVE-2012-3524), but by calling setresuid() you lost that protection. If
you're going to do that, there is little that libraries or executables
can do to save you.

sudo attempts to have a comprehensive blacklist (plugins/sudoers/env.c
in my copy) but IMO, its length demonstrates that any blacklist-based
approach is unsustainable. I continue to believe that any setuid program
that executes non-trivial code without whitelist-filtering its
environment is seriously flawed; and sh(1), as invoked by system(), is
certainly non-trivial.

Or to put it another way, executables that make themselves a privilege
boundary can't trust what they receive from outside the boundary, and
need to take responsibility for passing a sanitized version to things
inside the boundary - doubly so if the things inside the boundary have
no way to detect that a privilege boundary was ever crossed.

    S

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.