From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id d8c7130f for ; Tue, 12 Nov 2019 23:23:21 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 0233B9C6A0; Wed, 13 Nov 2019 09:23:19 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 52D749C11B; Wed, 13 Nov 2019 09:22:59 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=bsdimp-com.20150623.gappssmtp.com header.i=@bsdimp-com.20150623.gappssmtp.com header.b="WnpEaNe6"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id BA8C89C10C; Wed, 13 Nov 2019 09:22:57 +1000 (AEST) Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) by minnie.tuhs.org (Postfix) with ESMTPS id 0F85D9BB79 for ; Wed, 13 Nov 2019 09:22:57 +1000 (AEST) Received: by mail-qk1-f171.google.com with SMTP id z16so102877qkg.7 for ; Tue, 12 Nov 2019 15:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/+uxUU5rjoMwz5/dqjf6zMzi99/BVQb3ImwVbUD5ouE=; b=WnpEaNe6uHe0PxvTVW9XR53bxwavCrgR0Hd5NAACjlv4HGOgAwhlaRhvdTHHnbo9A+ WG7IU0EJdUuH6H6ipFnWrhekoAQVwRJ6tCxgyHaRezwbhdRnN6cNkBaF8kvdR4a+kw4L YjhogZtY/aJD13G9t1LAFkhF7thQMA4Vvi4W+ilwUhEMAOgNBeOH8XJ9JCIeA68vZ3IO DLZgL/nl2AO69yQwAOUt43sh15WysKpCLDMTT48nLbjr4dO3L0cobMX+EO7oxQzmorqm gsqpv6bcY9s+jRK0GpxynmzM1JEz9bO7qQwn6deq1SXrd60DYM7rqMuTYtgpvXWPi9+t 0MqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/+uxUU5rjoMwz5/dqjf6zMzi99/BVQb3ImwVbUD5ouE=; b=nPFmksbw6Ergq+FS9n8BCG+hf6Z2r8bV3dlbYEP0ycZDZoRnZfIZn4hukN8Maa+onz E5v0mwXN8agHoe2hXrdL6CTZ7//T/m7eTlKRngtfVnnoitqd4ff66UpsGRSzIpUQW4/a f/4cS9ne6B++pcvq9SzwfHypijkDuPydX8927eOZJpf6imrW1k4PcQGyLtIcPOJ2Diw/ 2yz/Qrud07YEA7Hzf8iQuWvmKufDnYJj/6sFOsfe1X4qnVOschpZSkjNy9blv+RVekhL WvG9mGkBNoTPt6E61nQp92fqB685frS5Tyv24YGgz+vfhd96/oU2dIC8ZOwEMC++6PUb +ISw== X-Gm-Message-State: APjAAAX7ZvutHZXi2s9W57fyPYqzF5p+iW5UyFhg9aUDcwnF8wqOlDXQ PHMnnYLghVps+lSTyf4//3w7RcQBKs9bH684Bw2BfA== X-Google-Smtp-Source: APXvYqzD+O0TO1wI2SBJEhycnrVrhKQKKox7qjyTm+2lA4OH4dhASBUC1V9FuNcdt9jFVdrFUABFB0neaBo2UQdMWY0= X-Received: by 2002:a05:620a:8c1:: with SMTP id z1mr336qkz.380.1573600975683; Tue, 12 Nov 2019 15:22:55 -0800 (PST) MIME-Version: 1.0 References: <1573592179.5935.for-standards-violators@oclsc.org> <20191112221053.C2009156E80B@mail.bitblocks.com> In-Reply-To: From: Warner Losh Date: Tue, 12 Nov 2019 16:22:44 -0700 Message-ID: To: Dave Horsfall Content-Type: multipart/alternative; boundary="0000000000002cb40c05972e87b0" Subject: Re: [TUHS] buffer overflow (Re: Happy birthday Morris worm X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000002cb40c05972e87b0 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 12, 2019 at 3:54 PM Dave Horsfall wrote: > On Tue, 12 Nov 2019, Bakul Shah wrote: > > > Unfortunately strcpy & other buffer overflow friendly functions are > > still present in the C standard (I am looking at n2434.pdf, draft of > > Sept 25, 2019). Is C really not fixable? > > No; POSIX requires all sorts of broken functions be present, otherwise it > is not compliant; heck, last I looked it even requires gets(). And let's > not even mention pointers... We are our own worst enemy.[*] > POSIX can't even recognize that leap seconds exist :( > All is not lost, though; use strncpy() instead of strcpy() etc. These > days my first choice is Perl, despite it being bloated (I only use C if > it's trivial or I need the speed). I must look at Ruby, though... > strncpy has two issues. First, it doesn't guarantee NUL termination. Second, it always writes N bytes. It's for a fixed width data field, not a variable length string whose buffer size is known. strlcpy is much better, but still has some issues... Warner --0000000000002cb40c05972e87b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 12, 2019 at 3:54 PM Dave = Horsfall <dave@horsfall.org>= wrote:
On Tue, = 12 Nov 2019, Bakul Shah wrote:

> Unfortunately strcpy & other buffer overflow friendly functions ar= e
> still present in the C standard (I am looking at n2434.pdf, draft of <= br> > Sept 25, 2019). Is C really not fixable?

No; POSIX requires all sorts of broken functions be present, otherwise it <= br> is not compliant; heck, last I looked it even requires gets().=C2=A0 And le= t's
not even mention pointers...=C2=A0 We are our own worst enemy.[*]

POSIX can't even recognize that leap seconds= exist :(
=C2=A0
All is not lost, though; use strncpy() instead of strcpy() etc.=C2=A0 These=
days my first choice is Perl, despite it being bloated (I only use C if it's trivial or I need the speed).=C2=A0 I must look at Ruby, though...=

strncpy has two issues. First, it does= n't guarantee NUL termination. Second, it always writes N bytes. It'= ;s for a fixed width data field, not a variable length string whose buffer = size is known. strlcpy is much better, but still has some issues...

Warner
--0000000000002cb40c05972e87b0--