[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 26 Jul 2012 12:47:53 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
CC: krahmer@...e.de
Subject: Re: libdbus hardening
On 10/07/12 14:09, Sebastian Krahmer wrote:
> We are going to add a libdbus hardening patch:
>
> https://bugzilla.novell.com/show_bug.cgi?id=697105
>
> This is because some suid binaries (Xorg and others) are linked against libdbus
The tl;dr: version if (e.g.) your Xorg binary still uses HAL and is also
setuid, ensure that it cleans its environment using a whitelist before
its first use of libdbus, libhal, any other non-trivial library, or exec().
In off-list discussion with the other D-Bus upstream maintainers,
consensus was that binaries with greater privileges than their parent
process (setuid or VFS capabilities) must not use non-trivial libraries
(e.g. libdbus, libhal, GIO or any scripting language), or run other
executables, without first sanitizing their environment using a
"whitelist" approach (start from a blank environment, set PATH etc. to
known-safe values, and copy only known-safe variables from the original
environment). Resetting the environment as close as possible to the
beginning of main() is wise.
In particular, we do not support use of libdbus in setuid binaries that
do not sanitize their environment before their first call into libdbus.
See
<http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/environment-variables.html>
for further advice.
Good examples:
* pkexec <http://cgit.freedesktop.org/polkit/tree/src/programs/pkexec.c>
has a small whitelist of environment variables to pass through
* The setuid wrapper generated by IkiWiki
<http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=IkiWiki/Wrapper.pm>
clears the environment and restores a small whitelist of CGI variables
before executing user code
* sudo appears to operate on a secondary environment internally, avoids
non-trivial libraries, and defaults to resetting the environment from a
whitelist
One maintainer specifically expressed opposition to "hardening" libdbus
if it will impede running non-setuid binaries unprivileged, under a fake
system bus, for regression testing. This rules out, for instance, using
secure_getenv() on systems with glibc >= 2.17 and always returning NULL
(i.e. assuming privilege) on other systems.
Using secure_getenv() on GNU systems and assuming *un*privileged
behaviour on non-GNU is not ruled out by that consideration, but leaves
non-GNU systems vulnerable. It also does not appear to address
executables with escalated privileges other than set*id (e.g. Linux VFS
capabilities). We believe that this makes it a poor substitute for
ensuring that setuid executables clear the environment properly, which
(in general) needs to be done anyway.
Regards,
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.
