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: Rich Felker <dalias at libc dot org>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 20 Jan 2015 16:37: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> <54BE5589 dot 3080802 at redhat dot com> <20150120151434 dot GG4574 at brightrain dot aerifal dot cx>
On 01/20/2015 04:14 PM, Rich Felker wrote:
> 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?
No, mainly because I'm not entirely sure what a POSIX TZ string should
look like.
I tried this, based on some test case:
$ TZ=AEST-10AEDST-11,M10.5.0,M3.5.0 strace -eopen date
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/share/zoneinfo/AEST-10AEDST-11,M10.5.0,M3.5.0",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Wed Jan 21 02:30:07 AEDST 2015
+++ exited with 0 +++
$ TZDIR=/tmp TZ=AEST-10AEDST-11,M10.5.0,M3.5.0 strace -eopen date
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/tmp/AEST-10AEDST-11,M10.5.0,M3.5.0", O_RDONLY|O_CLOEXEC) = 3
Tue Jan 20 15:30:14 UTC 2015
+++ exited with 0 +++
The file is copied from /usr/share/zoneinfo/UTC.
This seems to suggest that the glibc behavior is non-compliant.
--
Florian Weimer / Red Hat Product Security