[Bug libc/17100] New: secure_getenv() does not seem to properly detect if an environment is secure

[Bug libc/17100] New: secure_getenv() does not seem to properly detect if an environment is secure

[busterb at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17100

            Bug ID: 17100
           Summary: secure_getenv() does not seem to properly detect if an
                    environment is secure
           Product: glibc
           Version: 2.19
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: busterb at gmail dot com
                CC: drepper.fsp at gmail dot com

Until getauxval(AT_SECURE) was added, there did not appear to be a good way to
detect if a process is running setuid/setgid or not. You can find various
discussions about how to implement the BSD issetugid() function on Linux for
reference.

Checks like (uid==euid||gid==egid) can fail in various ways, e.g. it cannot
detect if a process has changed its uid/gid back, it is racy in multi-threaded
contexts, among other issues. I think that future glibc versions should only
use AT_SECURE, removing the getuid/geteuid check. If AT_SECURE is unavailable,
just assume the worst.

<snip>
     case AT_SECURE:
   seen = -1;
   __libc_enable_secure = av->a_un.a_val;
   __libc_enable_secure_decided = 1;

<snip>
__libc_init_secure (void)
{
 if (__libc_enable_secure_decided == 0)
   __libc_enable_secure = (__geteuid () != __getuid ()
               || __getegid () != __getgid ());
}

<snip>
char *
__libc_secure_getenv (name)
    const char *name;
{
 return __libc_enable_secure ? NULL : getenv (name);
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17100] secure_getenv() does not seem to properly detect if an environment is secure

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17100

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
__libc_enable_secure is computed by the libc initializer before any application
code is run.  No multi threading, no setuid/setgid calls.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17100] secure_getenv() does not seem to properly detect if an environment is secure

[joseph at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17100

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Sun, 29 Jun 2014, busterb at gmail dot com wrote:

> contexts, among other issues. I think that future glibc versions should only
> use AT_SECURE, removing the getuid/geteuid check. If AT_SECURE is unavailable,
> just assume the worst.

AT_SECURE is always available, since we removed support for pre-2.6 
kernels.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17100] secure_getenv() does not seem to properly detect if an environment is secure

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17100

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

--- Comment #3 from Florian Weimer <fweimer at redhat dot com> ---
Should we add a check which aborts if AT_SECURE is not present?  Beyond that,
there isn't anything libc can do here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17100] secure_getenv() does not seem to properly detect if an environment is secure

[busterb at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17100

--- Comment #4 from Brent Cook <busterb at gmail dot com> ---
Thank you for the clarification.

Though AT_SECURE is available in all kernels that glibc supports, is there be
any way for an adversary to cause the fallback case to be triggered through
external means?

That there is a fallback case is a little misleading since it does not also
perform the capabilities checks that the kernel does, so I don't think one
would want it to inadvertently execute on any kernel that implements
capabilities:

http://lxr.free-electrons.com/source/security/commoncap.c#L590

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17100] secure_getenv() does not seem to properly detect if an environment is secure

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17100

--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Brent Cook from comment #4)
> Though AT_SECURE is available in all kernels that glibc supports, is there
> be any way for an adversary to cause the fallback case to be triggered
> through external means?

No, the kernel prepares the aux vector as part of the execve implementation. 
It is possible to invoke the new process through userspace emulation, supplying
a bogus aux vector, but then, no privilege transition occurs, so there is no
security impact.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17100] secure_getenv() does not seem to properly detect if an environment is secure

[busterb at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17100

--- Comment #6 from Brent Cook <busterb at gmail dot com> ---
So at worst, the fallback case is a vestigial tail?

It would seem to be ready for the chopping block if so.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/17100] secure_getenv() does not seem to properly detect if an environment is secure

[joseph at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17100

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
elf/enbl-secure.c is used on Hurd as well as Linux, but I suppose that 
part of the code ought to be disabled if HAVE_AUX_SECURE.

-- 
You are receiving this mail because:
You are on the CC list for the bug.