[PATCH] tzset robustness [BZ#17715]
Florian Weimer
fweimer@redhat.com
Tue Jan 20 15:37:00 GMT 2015
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
More information about the Libc-alpha
mailing list