This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] tzset robustness [BZ#17715]
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>, Rich Felker <dalias at libc dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 20 Jan 2015 14:18:01 +0100
- 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>
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.
It is certainly easier not to scrub the TZ variable because no
additional patch is required. But I'm worried that the TZ parser
crosses a trust boundary, and we'll have to patch it again (and again).
Ulrich already tried to robustify the parser in commit
97ac2654b2d831acaa18a2b018b0736245903fd2, BZ #13506, but missed a few
corner cases. I don't feel very confident that my latest patch
addresses all remaining issues.
--
Florian Weimer / Red Hat Product Security