From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brown.elm.relay.mailchannels.net (brown.elm.relay.mailchannels.net [23.83.212.23]) by sourceware.org (Postfix) with ESMTPS id 00F7E3858D37 for ; Thu, 7 Apr 2022 06:26:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 00F7E3858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id BA066120F31; Thu, 7 Apr 2022 06:26:27 +0000 (UTC) Received: from pdx1-sub0-mail-a307.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 3EA30120661; Thu, 7 Apr 2022 06:26:27 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1649312787; a=rsa-sha256; cv=none; b=7AJKTANbx9yOALpFRL2jeCG9qcWbBQjwQn8YRp6X2ZVFozeGLyQbbNkircKjF4KNqftmkJ cJ856VnbHnJ3aM/S+kCTqD5AVeC3sCNUroLz2uaZha+z3VVLvbb4yMAuZRbAxcEu3/F/6O 2ATZpqsVYEyFVCjIZ5VAVLm8B0jeQnPQoLw0yHulGra4l9FvrY3je21a2vaLqXPLT5HH1L cmkuCnvgmvfYsvxIQAdHQd6pIUZxCjR9IxziKw16h0iYI0E2eXevQUhwwp/IxGFTXDYYFF Z7zwNK2NK9HCYjM08DvV+pIw053cyXo+ikmyA9anxq1uYJbsBakyEneKzqT0HA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1649312787; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=6S1iiboW7jSvZGO2qlsxcR2FqtJdz6AmP8gjJihx3Jg=; b=b0LBHhgkVIzVBHDpDN3Fmq9lOtwyUbdi4X9h2cpmBC4uRItNmVsdrvHSfzah6knB8Sx6kO 52goCU/6e0P1nhogg6JkI5IuNh0sdiJs9PqhB8+vEG25NLpBfzeKzX9n62ZNlZlXrYZ8ua d2zS2pSoxrQRyecmzXOVVxXAtQG2kDvU25gQ2KB9XyJ52pQnDQbB47cqDvRYBQEwpLahR0 zUmY2szGZN9Y2AcsvNOmPNjbFMZG7REOyf0V+PBj2IaWWsAqoKp70j74hlBZJrMEUrue5L 5GESV31iOUyzF9nfW4BrYIrDm99puuPAPVRBe6q1xY6XLM0vYDwHeIUvzSrj2Q== ARC-Authentication-Results: i=1; rspamd-786f77c8d-wq7kg; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a307.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.124.238.113 (trex/6.7.1); Thu, 07 Apr 2022 06:26:27 +0000 X-MC-Relay: Junk X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Wipe-Chemical: 5f16cd5611b9c256_1649312787553_2224104468 X-MC-Loop-Signature: 1649312787553:1562182572 X-MC-Ingress-Time: 1649312787553 Received: from [192.168.1.174] (unknown [1.186.223.102]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a307.dreamhost.com (Postfix) with ESMTPSA id 4KYrxW56DGz1PZ; Wed, 6 Apr 2022 23:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1649312787; bh=6S1iiboW7jSvZGO2qlsxcR2FqtJdz6AmP8gjJihx3Jg=; h=Date:From:Subject:To:Cc:Content-Type:Content-Transfer-Encoding; b=jDP8VrLEfLxZH2XtgoCSD8BeV3AE/riVS5WHJwvDc8zrdfT4KpD9Bd6VZks5DQcGZ 5tcB5nTXFhCNxTHLuPse9qeJKl/eKT0s7nN0L53RhmrPXwsUdOIlFRLSZKzir67DXm smr+KrIPdRepu9jaLBxJXj1+svf9TZixYr++65T7zhDiUHFqHVvx8YcF6+VBrHIdRY uPjQtprMcMVQcLCIfx/u2NthuDXHmNvN8/zdI1m5sT2kd2diAQGXrIprBAzrCYzoTp q+gijvibn4t/iHwZisI9izDpR+IkrZZuMsmtjjqgbbRAqQFwWXmIbQ7BcL2z0/q/rt TufAH2Y5ZaLTA== Message-ID: Date: Thu, 7 Apr 2022 11:56:18 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US From: Siddhesh Poyarekar Subject: [RFC] _FORTIFY_SOURCE strictness To: libc-alpha@sourceware.org Cc: Adhemerval Zanella , Andreas Schwab , Carlos O'Donell , Florian Weimer , Jakub Jelinek , =?UTF-8?Q?Martin_Li=c5=a1ka?= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3028.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 06:26:31 -0000 Hi, _FORTIFY_SOURCE levels up to 2 rely on static object size computation to make decisions at compile time to either call a fortified bounds-checking variant or a regular variant of a function. Because the size estimates were static and often upper limit estimates, the bounds were either optimistic or not present at all. This made aggressive bounds checks such as those in __snprintf_chk[1] or __wcrtomb_chk[2] safe enough as to have low false positives (where there's no actual buffer overflow but we have defined stricter requirements in the fortified functions) and hence pass through uncontested. This situation has changed with _FORTIFY_SOURCE=3, where it is now possible to get non-constant expressions for object sizes, providing not just more precise estimates, but also greater coverage, which appears to have increased the possibility of such false positives. This is not limited to the two known examples either; __strncpy_chk for example will crash if n is greater than the destination buffer size and is similarly prone to such false positives. One could envision a situation where an strncpy call is deeply nested and through compiler advances and attribute annotations, the callsite now gets precise size expressions for the call and not just an upper limit estimate or a (size_t)-1. Of course, good defensive programming practice means that one always pass n that is within limits of both source and destination bounds in strncpy but is a runtime check the right place to enforce good practices as opposed to only crashing on actual overflows? There appear to be two alternatives out of this situations and I wanted to build consensus around one of these or even a third alternative that I hadn't thought of. I of course volunteer to work on the approach we have consensus on: Option 1: Do nothing We could take the stand that it is what it is and that fortification checks are necessarily stricter than standards allowances to enforce better application programming practice. In this case I propose we improve the overflow messages to clearly indicate that we're enforcing a stricter limitation than the standard requires and not give the incorrect impression that we _detected_ an overflow. The downside of this approach is the possibility that some applications don't fortify beyond level 2, insisting that their usage is safe enough. At the moment it seems like a reasonably small set of applications are running into these, so maybe it's OK? Option 2: Improve checking accuracy at _FORTIFY_SOURCE=3 This would involve making the checking functions smarter, at level 3 and abort only on actual overflows. This could have a small runtime overhead in cases like __wcrtomb_chk but a larger one for cases like __snprintf_chk. It is also a more invasive change since it will involve changing all implementations. This essentially is similar to sanitizer-like functionality. The downside of this approach is the possibility that some applications don't fortify beyond level 2 because the performance overhead is unacceptable. Thoughts? Maybe an Option 3 that's less worse than the above two options? Thanks, Siddhesh [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28989 [2] https://lists.gnu.org/archive/html/bug-ncurses/2022-04/msg00002.html