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.