This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Tunables-related security regression
- From: Zack Weinberg <zackw at panix dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at gotplt dot org>
- Date: Mon, 23 Jan 2017 07:37:47 -0500
- Subject: Re: Tunables-related security regression
- Authentication-results: sourceware.org; auth=none
- References: <e9cbe93c-e788-f67c-bfce-4c8feda220e0@redhat.com>
On Mon, Jan 23, 2017 at 5:38 AM, Florian Weimer <fweimer@redhat.com> wrote:
>
> We have three different kinds of environment variables:
>
> (1) variables which are removed when AT_SECURE is active
> (2) variables which are ignored when AT_SECURE is active
> (but they are passed to subprocesses, where AT_SECURE
> may not be in effect)
> (3) variables which are not treated in any special way
>
> LD_DEBUG is in category (1), HESIOD_CONFIG is in (2), and TZ is in (3).
We should probably not have category (2) at all. If a variable is
unsafe for direct use in an AT_SECURE process, it is almost certainly
also unsafe for use in a non-AT_SECURE process *when invoked as a
subprocess of an AT_SECURE process*.
"Rewriting of GLIBC_TUNABLES" also makes me very nervous. I
understand that this is an umbrella variable containing both things
that are safe and things that are unsafe, but it's better to do as
little parsing of untrusted input as possible. Do we really _need_ to
be able to tune AT_SECURE programs?
(Glancing at the code, I see a bunch of other problems in this area,
starting with "why are there two copies of the sanitizer?" and "the
sanitizer only runs _after_ a bunch of LD_variables are processed"...
sigh.)
zw