From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) by sourceware.org (Postfix) with ESMTPS id D18A23858C01 for ; Wed, 4 Oct 2023 12:20:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D18A23858C01 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-ot1-x336.google.com with SMTP id 46e09a7af769-6c4b9e09528so1331763a34.3 for ; Wed, 04 Oct 2023 05:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696422021; x=1697026821; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=l0xdI/cNJFVaysLWNy43lDODjjEJmQMvjEa+og0sX70=; b=hSCuU4vP/7oS/32z79etb+QbQxQ03z0wKT3c4Vu5y5O+ID4VYRoluo+2Z33fWaI17Y h2vC+K1Ssdyo5XXXg8cc4bCXH+aqntmuPn8IVorMvJgtG4bsUYvN79q5hWpZXj2O/ZKk lLj3N3Kwyumvw6He/hVPrP6iKWC/kjDQxS3ZJ7lmBfotWI1iK2RK58wxYD4HCzwDKt5S wkoabxS46Ocyw7LbL9EQcXlDUXx6jErrWIEhGuXBNXUHEqtdcqYJScKGw3w5S0OAy6MW mZEwxtGT2bgiD49u6zR9ThZcGYPgQVqilQFAmczbs9Bh6eXbd/8nq7MnRMc5OZe0GIsD WlrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696422021; x=1697026821; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=l0xdI/cNJFVaysLWNy43lDODjjEJmQMvjEa+og0sX70=; b=XnrxZ5CztAvICQgR4DrYsJaSxIsRSIjDYTFfNU+TXXzI2kCjTWByNbejOmAEyfjI3n ndAhYDuyXuQhIeKSGawq/NK3Q6MuseWg1hKaiA5ZVWbGObndSasgCYONl6IP03IpCNdJ kedqgLZqke20lE81pNtByzuv3kIcgLF6v6bfd8hiwzkE4QuXdJaVklfQ1YN0BojQ/ta5 cN1UZxoq9frd2WIhw1MEqWQV9R7J0c+Apa9eauCoOH/5jPJX6eluRtb8kV/PTaMeIFhi JjLz4kkqPQ9gkJ/TypUInCNgWsb7GZCbhhUSJPV8ru46GvOraxeF93uZLUZmPJ68hyP4 8B6w== X-Gm-Message-State: AOJu0YyikUXKeky/MG09XwGuyMcVnfaNQo6pmmkwTYCk1332bQRvYkHn KScZ/52OqmU/Ne40FRFVifVx0w== X-Google-Smtp-Source: AGHT+IHWOW0rosKi7s86tvrQQXnJeBZK3HhS5VcUMdYowtPxTwpUCUFhuxrAH+45FFUgUKrbtR3n0Q== X-Received: by 2002:a05:6358:430b:b0:132:d333:4a5c with SMTP id r11-20020a056358430b00b00132d3334a5cmr1958443rwc.10.1696422020800; Wed, 04 Oct 2023 05:20:20 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:feaf:b959:23ff:3a18:c5dc? ([2804:1b3:a7c1:feaf:b959:23ff:3a18:c5dc]) by smtp.gmail.com with ESMTPSA id x13-20020a056a00270d00b0068bbe3073b6sm3103074pfv.181.2023.10.04.05.20.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Oct 2023 05:20:20 -0700 (PDT) Message-ID: Date: Wed, 4 Oct 2023 09:20:17 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [committed 2/2] tunables: Terminate if end of input is reached (CVE-2023-4911) Content-Language: en-US To: Siddhesh Poyarekar , libc-alpha@sourceware.org Cc: Carlos O'Donell , Arjun Shankar References: <20231003170811.64957-1-siddhesh@sourceware.org> <20231003170811.64957-3-siddhesh@sourceware.org> <51a2d2d6-883b-44e5-b857-33337d3260e0@linaro.org> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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.