This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] tzset robustness [BZ#17715]
- From: Rich Felker <dalias at libc dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 15 Jan 2015 09:02:09 -0500
- Subject: Re: [PATCH] tzset robustness [BZ#17715]
- Authentication-results: sourceware.org; auth=none
- References: <54B6E99E dot 4030109 at redhat dot com> <20150115133911 dot GR4574 at brightrain dot aerifal dot cx> <54B7C493 dot 5020506 at redhat dot com>
On Thu, Jan 15, 2015 at 02:45:55PM +0100, Florian Weimer wrote:
> On 01/15/2015 02:39 PM, Rich Felker wrote:
> >On Wed, Jan 14, 2015 at 11:11:42PM +0100, Florian Weimer wrote:
> >>This patch removes two different unbounded alloca calls, and also
> >>fixes the TZ parser issue identified here:
> >>
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772705
> >>
> >>This is not my preferred approach. I would rather like to sanitize
> >>TZ in AT_SECURE mode, so that specifying a file from a non-default
> >>TZDIR does not work. However, this alternative approach is a bit
> >>involved because the current ld.so setup code is not fit to handle
> >>content-dependent environment variable scrubbing.
> >
> >Doing the scrubbing in the dynamic linker does not seem appropriate
> >anyway. It wouldn't solve the problem for static-linked binaries and
>
> I have working scrubbing for statically linked binaries, I think.
>
> >it would wrongly remove environment entries rather than just ignoring
> >them. Instead, tzset should be doing its own path enforcement based on
> >the presence of getauxval(AT_SECURE) or similar (e.g. the proposed
> >issetugid function).
>
> We already do that, but we aren't consistent about it: We scrub
> TZDIR unconditionally (which is cleared in AT_SECURE mode), but we
> pass TZ variables containing absolute paths to subprocesses. The
> latter means that the TZDIR scrubbing isn't effective.
I fail to see how removing env vars behind the program's back is
conforming. I understand that the _intent_ is to improve security, but
IMO any contract violation such as this is a potential cause of
vulnerabilities in itself (e.g. as a silly example, suppose the child
process you were executing is a tool that examines the environment and
exits with 0/1 to tell if the environment contained anything
dangerous).
Rich