oss-sec mailing list archives
Re: libdbus hardening
From: Simon McVittie <smcv () debian org>
Date: Thu, 26 Jul 2012 12:47:53 +0100
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
Current thread:
- Re: libdbus hardening, (continued)
- Re: libdbus hardening Sebastian Krahmer (Jul 11)
- Re: libdbus hardening Solar Designer (Jul 11)
- Re: libdbus hardening yersinia (Jul 11)
- Re: libdbus hardening Solar Designer (Jul 17)
- Re: libdbus hardening Florian Weimer (Jul 17)
- Re: libdbus hardening Florian Weimer (Jul 25)
- Re: libdbus hardening yersinia (Jul 26)
- Re: libdbus hardening Ludwig Nussel (Jul 30)
- Re: libdbus hardening Florian Weimer (Jul 30)
- Re: libdbus hardening Ludwig Nussel (Jul 30)
- Re: libdbus hardening Sebastian Krahmer (Jul 11)
- Re: libdbus hardening Ludwig Nussel (Jul 30)