From: Rich Felker <dalias@libc.org>
To: "David A. Wheeler" <dwheeler@dwheeler.com>
Cc: libc-alpha <libc-alpha@sourceware.org>
Subject: Re: Implement C11 annex K?
Date: Fri, 22 Aug 2014 00:37:00 -0000 [thread overview]
Message-ID: <20140822003706.GM12888@brightrain.aerifal.cx> (raw)
In-Reply-To: <E1XKb6n-0005Nu-Ap@rmm6prod02.runbox.com>
On Thu, Aug 21, 2014 at 06:45:29PM -0400, David A. Wheeler wrote:
> On Mon, 18 Aug 2014 01:03:30 -0700, Paul Eggert <eggert@cs.ucla.edu> wrote:
> > OpenSSH's authors have strongly
> > advocated strlcpy and have much invested in it over the years. Even if
> > they conceded that strlcpy is not that helpful now (admittedly
> > unlikely), inertia would probably induce them to keep it.
>
> There are now *hundreds* of packages that use strlcpy/strlcat.
> It is NOT just the original OpenSSH authors that use them.
> Every package has to keep re-implementing them, typically in less-efficient
> portable ways, because glibc fails to include them.
This is exactly my reason for wanting them in glibc: I've repeatedly
seen buggy re-implementations that probably introduce new security
bugs. Even if these functions are bad (and I think they are), they're
sufficiently famous that lots of people cargo-cult the API (but not
the implementations) into their software, thereby introducing new
security bugs.
> Here's a list put together by deraadt, there are probably others:
> http://marc.info/?l=openbsd-tech&m=138733933417096&w=2
Thanks for digging this up!
> > > addrmatch.c:321:
> > > ... The one-line snprintf version is this horror:
> >
> > That's because you wrote it in a horrible way. This is better:
> >
> > if (snprintf(addrbuf, sizeof addrbuf, "%s", p) >= sizeof addrbuf)
> > return -1;
>
> The spec says snprintf can return <0, which this code fails to handle.
> It's still not better, anyway; it sure isn't obvious that this is a string copy.
> But to continue...
This is simply wrong as I already addressed. The resulting type of the
sizeof operator is size_t, and on all systems of any practical
interest, size_t has integer conversion rank higher than (signed) int.
Thus any negative value, after conversion, is >=INT_MAX, and in
practice, >= the size of any struct.
> > Though I wouldn't use snprintf here, as the following distinguishes the
> > check from the action more clearly:
> >
> > if (strlen(p) >= sizeof addrbuf)
> > return -1;
> > strcpy(addrbuf, p);
>
> No. That wastes a lot of *people* time and is dangerous during maintenance.
> In many projects, every strcpy() will (correctly) set off warning bells
> requiring multiple people to *prove* that it can't exceed the buffer overflows.
> And it's not just during writing the initial code. It's also easy to turn this kind
> of code into a vulnerability when the code is maintained
> (which is one reason this kind of code wastes a lot of people-time),
> so every time the function is changed, people will have to re-check it, and
> over time this can get painful.
>
> So every strcpy(), even if it's safe, increases *development* and *maintenance* time.
> Developer and reviewer time is often MORE important than execution time
> (even in C code, only some paths usually matter).
> It's not TOO hard in this case to show that the strcpy cannot be
> exceeded, sure, but that's not the end.
For the most part I agree with this argument. I've used the same
argument to reject use of sprintf as an "optimization" over snprintf
even where it's easy to prove that sprintf would be safe.
> > Worse, this use of strlcpy has undefined behavior
> > when cp points into buf.
>
> I don't think so. strlcpy is required to copy the source left-to-right, since it stops at the \0,
> and it's copying to the beginning of "buf", so I don't see an undefined behavior.
Are you sure? For standard functions this is false; aside from memcpy,
they are all documented with:
"If copying takes place between objects that overlap, the behavior is
undefined."
Since this is the general pattern, I would treat use of
strlcpy/strlcat with overlapping buffers as UB unless they're
explicitly documented to support such usage. Note that, if they are
documented to support overlapping buffers, this is another thing that
re-implementors could easily get wrong.
Rich
next prev parent reply other threads:[~2014-08-22 0:37 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1407616492.31098.ezmlm@sourceware.org>
2014-08-09 20:52 ` David A. Wheeler
2014-08-10 7:52 ` Andreas Jaeger
2014-08-10 15:03 ` Adhemerval Zanella
2014-08-11 15:32 ` Joseph S. Myers
2014-08-11 15:52 ` Paul Eggert
2014-08-11 16:06 ` Joseph S. Myers
2014-08-11 15:56 ` David A. Wheeler
2014-08-12 4:23 ` Rich Felker
[not found] ` <3565dfa0-060c-46b9-b08c-6edc4eaa1179@email.android.com>
2014-08-12 21:00 ` Rich Felker
[not found] ` <d4ae8119-f629-4235-8981-dd2ccc220fea@email.android.com>
2014-08-12 22:08 ` Rich Felker
2014-08-12 23:15 ` David A. Wheeler
2014-08-12 23:48 ` dalias
2014-08-13 19:23 ` David A. Wheeler
2014-08-13 19:44 ` Adhemerval Zanella
2014-08-13 19:45 ` Adhemerval Zanella
2014-08-13 20:49 ` Rich Felker
2014-08-13 20:41 ` dalias
2014-08-13 20:55 ` Joseph S. Myers
2014-08-13 21:25 ` Paul Eggert
2014-08-13 21:35 ` Rich Felker
2014-08-13 22:46 ` Tolga Dalman
2014-08-13 23:59 ` Russ Allbery
2014-08-14 0:55 ` Joseph S. Myers
2014-08-14 1:01 ` Russ Allbery
2014-08-14 2:25 ` Rich Felker
2014-08-14 5:25 ` Russ Allbery
2014-08-14 5:46 ` Rich Felker
2014-08-14 6:15 ` Russ Allbery
2014-08-14 9:55 ` Florian Weimer
2014-08-14 10:02 ` Andreas Schwab
2014-08-14 10:06 ` Florian Weimer
2014-08-14 10:13 ` Andreas Schwab
2014-08-14 16:26 ` Rich Felker
2014-08-14 16:53 ` Andreas Schwab
2014-08-14 17:04 ` Rich Felker
2014-08-18 7:31 ` Andreas Schwab
2014-08-18 19:20 ` Rich Felker
2014-08-14 15:20 ` Paul Eggert
2014-08-14 17:20 ` Russ Allbery
2014-08-14 17:46 ` Rich Felker
2014-08-15 7:51 ` Florian Weimer
2014-08-14 6:08 ` Paul Eggert
2014-08-15 14:25 ` David A. Wheeler
2014-08-15 15:36 ` Paul Eggert
2014-08-15 16:14 ` David A. Wheeler
2014-08-15 16:39 ` Rich Felker
2014-08-15 22:01 ` David A. Wheeler
2014-08-16 2:19 ` Rich Felker
2014-08-16 2:26 ` Russ Allbery
2014-08-16 2:49 ` Rich Felker
2014-08-16 3:03 ` Russ Allbery
2014-08-15 22:04 ` Paul Eggert
2014-08-15 22:25 ` David A. Wheeler
2014-08-15 22:43 ` Adhemerval Zanella
2014-08-16 4:41 ` David A. Wheeler
2014-08-16 5:01 ` Rich Felker
2014-08-17 18:03 ` David A. Wheeler
2014-08-17 19:05 ` dalias
2014-08-17 20:33 ` David A. Wheeler
2014-08-17 23:25 ` Rich Felker
2014-08-18 0:59 ` David A. Wheeler
2014-08-18 0:15 ` David A. Wheeler
2014-08-18 8:03 ` Paul Eggert
2014-08-18 19:22 ` Rich Felker
2014-08-21 22:45 ` David A. Wheeler
2014-08-22 0:37 ` Rich Felker [this message]
2014-08-22 1:39 ` William Park
2014-08-22 1:53 ` Jonathan Nieder
2014-08-22 4:36 ` William Park
2014-08-22 2:32 ` Paul Eggert
2014-08-22 2:51 ` Rich Felker
2014-09-08 23:21 ` David A. Wheeler
2014-09-09 3:34 ` Paul Eggert
2014-08-13 22:20 ` Time to add strlcpy/strlcat FINALLY David A. Wheeler
2014-08-14 1:09 ` Paul Eggert
2014-08-14 2:34 ` Rich Felker
2014-08-14 3:02 ` William Park
2014-08-14 13:01 ` Mike Frysinger
2014-08-15 10:37 ` Michael Kerrisk (man-pages)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140822003706.GM12888@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=dwheeler@dwheeler.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).