From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87714 invoked by alias); 25 Jul 2017 03:10:12 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 87368 invoked by uid 89); 25 Jul 2017 03:10:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=initiative, secure X-HELO: mail-qt0-f193.google.com Received: from mail-qt0-f193.google.com (HELO mail-qt0-f193.google.com) (209.85.216.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 25 Jul 2017 03:10:00 +0000 Received: by mail-qt0-f193.google.com with SMTP id t37so246291qtg.2 for ; Mon, 24 Jul 2017 20:10:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jntBCW5uqUoC14h8s+JU+aezL89AouJ6pXZjALQ/MxI=; b=gB3uE5IR68SpDf0hNztYRF/dFm3BNUuWs2V48/gt4Zj0ZolK9t2SVM/sxp3LddoTT6 wZGvi796vtWzcryVW/ZGFCtCGN9SpGZeB2syS7uNF6dGCU1aA301ZI4Q4hjAh9/EscPh cHxHHxA1vbuLDYrhNusZfWgjGZEontY/BlubHwID80SZv3CJBVMWsTjfRZTMJFpFXnX2 bFXXftSvOf6sTdNPiBR7uCYssXpa+GAVpxETlQ4cy2Dxo/22p71DT5VCpmh9ejOs4R+N OumT6xT+QrDa+axLlARqZ6upJoAjUmdyNoOK1NT9iEneytwp5yrkyxBP4r6iB/LoGv2e i3Ug== X-Gm-Message-State: AIVw110eV421Li1w93n5ZRnieBhAFcc7IEbg2ZKCnAziKXYmfzWxTgkl ATrzxOUEBU9J1xLL X-Received: by 10.237.53.172 with SMTP id c41mr14546654qte.33.1500952198531; Mon, 24 Jul 2017 20:09:58 -0700 (PDT) Received: from localhost.localdomain (75-171-229-159.hlrn.qwest.net. [75.171.229.159]) by smtp.gmail.com with ESMTPSA id l12sm9615244qtl.24.2017.07.24.20.09.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jul 2017 20:09:58 -0700 (PDT) Subject: [PING #2] [PATCH] enhance overflow and truncation detection in strncpy and strncat (PR 81117) To: Gcc Patch List References: <13944863-99a8-4144-1703-c6e1a2f36425@gmail.com> From: Martin Sebor Message-ID: <8560fee6-86bd-ebf7-10d8-298583fec4b3@gmail.com> Date: Tue, 25 Jul 2017 03:10:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg01486.txt.bz2 Ping #2: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00411.html > > On 07/08/2017 02:45 PM, Martin Sebor wrote: >> PR 81117 asks for improved detection of common misuses(*) of >> strncpy and strncat. The attached patch is my solution. It >> consists of three related sets of changes: >> >> 1) Adds a new option, -Wstringop-truncation, that diagnoses calls >> to strncpy, and stpncpy (and also strncat) that truncate the copy. >> This helps highlight the common but incorrect assumption that >> the first two functions NUL-terminate the copy (see, for example, >> CWE-170) For strncat, it helps detect cases of inadvertent >> truncation of the source string by passing in a bound that's >> less than or equal to its length. >> >> 2) Enhances -Wstringon-overflow to diagnose calls of the form >> strncpy(D, S, N) where the bound N depends on a call to strlen(S). >> This misuse is common in legacy code when, often in response to >> the adoption of a secure coding initiative, while replacing uses >> of strcpy with strncpy, the engineer either makes a mistake, or >> doesn't have a good enough understanding of how the function works, >> or does only the bare minimum to satisfy the requirement to avoid >> using strcpy without actually improving anything. >> >> 3) Enhances -Wsizeof-pointer-memaccess to also warn about uses of >> the functions to copy an array to a destination of an unknown size >> that specify the size of the array as the bound. Given the >> pervasive [mis]use of strncpy to bound the copy to the size of >> the destination, instances like this suggest a bug: a possible >> buffer overflow due to an excessive bound (see, for example, >> CWE-806). In cases when the call is safe, it's equivalent to >> the corresponding call to memcpy which is clearer and can be >> more efficient. >> >> Martin >> >> PS By coincidence rather than by intent, the strncat warnings >> are a superset of Clang's -Wstrncat-size. AFAICS, Clang only >> warns when the destination is an array of known size and >> doesn't have a corresponding warning for strncpy. >> >> [*] Here's some background into these misuses. >> >> The purpose of the historical strncpy function introduced in V7 >> UNIX was to completely fill an array of chars with data, either >> by copying an initial portion of a source string, or by clearing >> it. I.e., its purpose wasn't to create NUL-terminated strings. >> An example of its use was to fill the directory entry d_name >> array (dirent::d_name) with the name of a file. >> >> The original purpose of the strncat function, on the other hand, >> was to append a not necessarily NUL-terminated array of chars >> to a string to form a NUL-terminated concatenation of the two. >> An example use case is appending a directory entry (struct >> dirent::d_name) that need not be NUL-terminated, to form >> a pathname which does. >> >> Largely due to a misunderstanding of the functions' purpose they >> have become commonly used (and misused) to make "safe," bounded >> string copies by safeguarding against accidentally overflowing >> the destination. This has led to great many bugs and security >> vulnerabilities. >> >