From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
Sent: Thursday, 28 October, 2004 14:23
On Wed, 27 Oct 2004 10:42:41 PDT, Michael Wojcik said:
You don't have to understand how to exploit a buffer overflow in
order to avoid overflowing buffers.
But you have to think of a buffer being overflowed to check for
it.
Anyone who doesn't understand that a finite-size container cannot hold more
than what it can hold is unlikely to manage to write software.
You don't have to understand SQL code-injection
attacks to restrict SQL input fields to valid characters.
But you have to realize that SQL can be fed invalid
characters to check for it.
No, you don't. It's enough to have a specification (that is, a contract)
which says that input X must contain data that meets certain criteria. From
that, the careful programmer will write a validation routine that rejects
input which fails to meet that criteria. It doesn't matter whether the
programmer has any understanding of SQL at all, much less what it may do
with its input. It suffices to know that the program specification imposes
requirements on the input.
You don't have to understand cross-site scripting by embedded
HTML to strip or sanitize HTML tags from user-supplied input
that shouldn't have them.
But you need to know which tags are safe and why, in order to
strip or sanitize it correctly.
No you don't. You just have to sanitize the input. The HTML specification
says that certain characters have special meaning and must be replaced with
character entities in ordinary text. If the program is producing output
that's supposed to be ordinary text, for consumption by an HTML agent, it
must perform those replacements. End of story. There's no need whatsoever
for the person writing that code to know anything more about HTML than which
characters need to be replaced, and with what. In fact, even that's
unnecessary, because the specification for the program should note that
those characters need to be replaced; the programmer can remain entirely
ignorant of HTML.
You don't need to understand how signed-integer overflow could
cause a problem to check for it.
But you need to understand it *can* be a problem to check for it..
See "finite-size container" above. I prefer to use code not written by
idiots.
But you need to understand at least the basics of THAT one to
check for it, too...
Puzzled by what goes there? Good. So am I - *neither* of us
thought of it.
Now it's *invisible* straw men.
And that's the point - whatever goes in that blank space was
certainly just as big a problem as SQL injection or integer
overflows or double-frees.
Really? I find it hard to be certain about imaginary entities, myself.
But we're both only human, and we'll look silly when the advisory
hits BugTraq or Full-Disclosure, and everybody will say "Look at
that, yet another dumb-ass programmer that didn't know enough to
check for *THAT*".
Ah, so this really boils down to "if we can't expect programmers to
anticipate all bugs, we can't expect them to anticipate any".
If you can't see where the fallacy is in *that*, then I don't see much point
in continuing this discussion.
I'm really not interested in excuses for programmers who fail to demonstrate
even a little discipline in their work. And that's precisely what Mangleme
has shown.
--
Michael Wojcik
Principal Software Systems Developer, Micro Focus
