This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] tzset robustness [BZ#17715]


On 01/15/2015 09:02 AM, Rich Felker wrote:
> On Thu, Jan 15, 2015 at 02:45:55PM +0100, Florian Weimer wrote:
>> On 01/15/2015 02:39 PM, Rich Felker wrote:
>>> On Wed, Jan 14, 2015 at 11:11:42PM +0100, Florian Weimer wrote:
>>>> This patch removes two different unbounded alloca calls, and also
>>>> fixes the TZ parser issue identified here:
>>>>
>>>>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772705
>>>>
>>>> This is not my preferred approach.  I would rather like to sanitize
>>>> TZ in AT_SECURE mode, so that specifying a file from a non-default
>>>> TZDIR does not work.  However, this alternative approach is a bit
>>>> involved because the current ld.so setup code is not fit to handle
>>>> content-dependent environment variable scrubbing.
>>>
>>> Doing the scrubbing in the dynamic linker does not seem appropriate
>>> anyway. It wouldn't solve the problem for static-linked binaries and
>>
>> I have working scrubbing for statically linked binaries, I think.
>>
>>> it would wrongly remove environment entries rather than just ignoring
>>> them. Instead, tzset should be doing its own path enforcement based on
>>> the presence of getauxval(AT_SECURE) or similar (e.g. the proposed
>>> issetugid function).
>>
>> 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.

c.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]