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: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 20 Jan 2015 10:14:34 -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> <20150115140208 dot GS4574 at brightrain dot aerifal dot cx> <54B9742E dot 3060301 at redhat dot com> <54BE5589 dot 3080802 at redhat dot com>
On Tue, Jan 20, 2015 at 02:18:01PM +0100, Florian Weimer wrote:
> On 01/16/2015 09:27 PM, Carlos O'Donell wrote:
> >>> 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).
> >
> > I can't help but agree. Removing env vars is a bad idea, ignoring them
> > is the only way I'd handle this.
>
> On the other hand, looking at TZDIR at all is non-confirming as well.
Are you sure? The way in which the TZ is processed when it's not a
POSIX TZ string is implementation-defined. Defining that to include
processing of the TZDIR environment variable is perfectly acceptable.
These interfaces are already permitted to access the environment so
there's no issue with concurrent environment access.
Rich