Re: Theo chiming in on strlcpy

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 22 Dec 2013 02:38:30 +0100
    From:        Marc Espie <espie%nerim.net@localhost>
    Message-ID:  <20131222013830.GA21044%lain.home@localhost>

  | Okay, so you think some buffer overflows can be not dangerous ?

Of course.  Some of them are just bugs.  Not every bug is dangerous,
some are just bugs - annoying, if they actually cause problems, of
simply benign if they just sit there, unobserved, which was the case
for the "potential, but absurd" problem that was found in nmh.

  | well, I say they're unpredictable (by nature),

No, they're not, almost nothing in software is unpredictable (just some
timing issues, which are almost never relevant to this kind of problem.)
What they can be is hard to track down - but once understood, it will all
be 100% predictable.   The case in question could only ever cause a problem
if the admin defined their hostname and domain to (combined) be way bigger
than are actually permitted for FQDNs (much bigger).   That is, the admin
deliberately setting out to sabotage his own software.   Sure, there is the
potential there for crashes, but do you really think anyone cares?  And no,
there was no potential for this to cause some other problem in some other 
place.

  | Oh yeah.  It's never happened for bugs to survive dozens of years and cause
  | security issues down the line, hasn't it ?

Of course that's possible, but blind adherence to some dogma will never
avoid that problem.

  | What kind of asserts ?

Not my business, but knowing the code in question, and its author, I think
I can believe that the checks will still be there at runtime.

But the issue was the blind substitution of strcpy() by strlcpy() (from
openbsd "auditing") and not bothering to do what you claim you're supposed
to do, and check for truncation...   When you do that, you're saying either
"it might have overflowed, now it can't, but now we have the wrong answers,
and we don't care", or "we know it was never going to overflow anyway, but
strcpy() is ***evil*** so we must replace it with strlcpy(), and by doing do
we gain brownie points ..."    In this case, I suspect it was the latter.

  | I know I won't change your mind. I don't care to.

Good, but you brought this issue to this list.  You didn't need to.

  | Nope, I'm more concerned about the undecided people.

So am I - and I hope they'll decide that software needs to be correct.
To be correct, it needs to be correctly written, using whatever tools
are chosen appropriately, and with good safety principles in mind.
If that's done, it doesn't matter if the tools chosen could be dangerous
in less experienced hands - and it is simply nonsense to claim that
anything built using a dangerous tool is necessarily inferior to a similar
product built using safer tools - the issue is all about how they're
used.

kre

ps: the code Theo chose to dig out of bind to show snprintf() being used
without checking its result was most amusing ... that was a case where
snprintf() is obviously overkill, and sprintf() would have been fine - the
buffer cannot be overflowed, unless an earlier function call has already
overflowed its buffer (in which case there bug would be in it, and nothing
that happens after it can be trusted, including snprintf calls or results).
What's more, that was obvious from looking at just the few lines posted.
If that's the best example that could be found, it kind of shows to folly
of arguing dogma, instead of reality, doesn't it?