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 11:54:32 -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> <20150120151434 dot GG4574 at brightrain dot aerifal dot cx> <54BE761D dot 5000808 at redhat dot com>
On Tue, Jan 20, 2015 at 04:37:01PM +0100, Florian Weimer wrote:
> 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.
Yes, glibc is wrongly attempting to process strings as filenames
first, then as POSIX-format TZ strings. I'd like to see this fixed,
but I suspect too many users would complain.
Rich