Re: [committed 2/2] tunables: Terminate if end of input is reached (CVE-2023-4911)

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 03/10/23 15:16, Siddhesh Poyarekar wrote:
> On 2023-10-03 14:07, Adhemerval Zanella Netto wrote:
>> So how should we handle what might be inconsistent invalid inputs like:
>>
>>    glibc.malloc.mmap_threshold=4096=4096
>>
>> Since glibc does not provide any TUNABLE_SECLEVEL_NONE, this tunables
>> will be ignored.  But for TUNABLE_SECLEVEL_NONE one, the value is
>> still parsed by _dl_strtoul or stored in the tunable.
>>
> 
> Ack, it probably makes sense to drop all tunables that don't match at this stage.  Arjun is going to rework the parsing for pr#30683 and it probably makes sense to, in addition to enhancing the parsing, also weed out invalid inputs and harden around allocations for the tunable string to provide some resilience against overflows.
> 
> The other aspect to think about may be the utility of passing tunables to (or through) setuid programs.  I had done it to maintain compatibility with the malloc envvars that were getting passed through, but maybe it's a good idea to filter all of them out.  Perhaps with systemwide tunables we could even have a way for tunables to be read in sxid programs in a safer way.

I think it would be best to avoid changing AT_SECURE binaries semantic
through tunables or even environment setting (/etc/suid-debug).  It
means adding back GLIBC_TUNABLES to unsecvars (so even non AT_SECURE
binaries won't see GLIBC_TUNABLES), do not process GLIBC_TUNABLES for
AT_SECURE (including malloc mcheck), and dropping any ill-formed
GLIBC_TUNABLES strings (so first parse and only apply well-formatted
ones).

This would allow to just remove the tunables_strdup altogether,
simplifying the code a lot.  It also means that any security tunable
(such as the glibc.mem.tagging) would also stop appling to AT_SECURE,
but I think we should stopping giving users to change secure binares
semantics even in this way.

And I don't think we should make this changes iff we have a a trusted
system-wide tunable.

I am working on coming up with this ideas, and we can discuss whether
adding trusting system-wide tunable would be a good idea.