oss-sec mailing list archives
Re: [PATCH] implement privmode support in dash
From: Simon McVittie <smcv () debian org>
Date: Thu, 22 Aug 2013 20:45:55 +0100
On 22/08/13 18:59, Tavis Ormandy wrote:
For example, here is one I just found in vmware-tools that manages to call popen("lsb_release") with effective uid zero: $ cc -xc - -olsb_release<<<'main(){system("sh>`tty` 2>&1");}';PATH=.:$PATH vmware-mount # whoami root
Having (da)sh drop privileges is a useful bit of hardening, but it doesn't help you if the vulnerable executable does a fork-and-exec without using the shell (at least with one of the exec variants that respects $PATH, like execvp), or some more friendly wrapper around fork-and-exec like posix_spawnp() or GLib's g_spawn family of functions. After researching this sort of thing a bit a few months ago, I'm of the opinion that any set*id executable that doesn't filter its environment through a whitelist is Doing It Wrong. If it might find that its caller is in fact trusted, or if it's going to drop to their privileges later, then saving the untrusted environment and putting it back later is fine - e.g. in an ideal world, sudo would save the untrusted environment, check its configuration, authenticate the user, and (depending on configuration) put none, part or all of the untrusted environment back before it execs the target executable. Unfortunately, many set*id executables don't do that: notably, many su(8) implementations call into PAM (and hence into arbitrary distribution- or sysadmin-chosen libraries) with a caller-supplied environment. I think sudo might do the same, but it wasn't clear to me. I asked the PAM mailing list what their security policy is[1] but haven't seen any reply so far. I didn't find anything actually exploitable at the time, but I didn't audit out-of-tree PAM plugins in any particular detail either. If the vulnerable executable uses non-trivial libraries, and those libraries don't second-guess what their caller actually intended to do (as e.g. libdbus and libgio now do, as a result of CVE-2012-3524), then you get the same situation. I don't think "make every library or helper binary that might conceivably be used in a set*id executable distrust its environment" is really an approach that scales - it's the set*id executable that's crossing a privilege boundary, not the library or helper binary (which doesn't necessarily even know what the caller's security model is), so I think the onus should be on the set*id executable to be suitably paranoid. S [1] https://www.redhat.com/archives/pam-list/2013-January/msg00005.html
Current thread:
- [PATCH] implement privmode support in dash Tavis Ormandy (Aug 22)
- Re: [PATCH] implement privmode support in dash Simon McVittie (Aug 22)
- Re: [PATCH] implement privmode support in dash Tavis Ormandy (Aug 23)
- Re: [PATCH] implement privmode support in dash Ludwig Nussel (Aug 23)
- Re: [PATCH] implement privmode support in dash Harald van Dijk (Aug 22)
- Re: [PATCH] implement privmode support in dash Tavis Ormandy (Aug 22)
- Re: [PATCH] implement privmode support in dash Jilles Tjoelker (Aug 22)
- Re: [PATCH] implement privmode support in dash Tavis Ormandy (Aug 22)
- Re: [PATCH] implement privmode support in dash Jérémie Courrèges-Anglas (Aug 23)
- Re: [PATCH] implement privmode support in dash Jérémie Courrèges-Anglas (Aug 23)
- Re: [PATCH] implement privmode support in dash Roy (Aug 23)
- Re: [PATCH] implement privmode support in dash Simon McVittie (Aug 22)