[7333] in bugtraq
Re: On compilers and bounds checking (was: EMERGENCY: new remote
daemon@ATHENA.MIT.EDU (Dale.Babiy)
Tue Jul 21 17:10:04 1998
Date: Tue, 21 Jul 1998 09:47:41 -0700
Reply-To: "Dale.Babiy" <Dale.Babiy@GOV.YK.CA>
From: "Dale.Babiy" <Dale.Babiy@GOV.YK.CA>
X-To: Andy Church <achurch@DRAGONFIRE.NET>
To: BUGTRAQ@NETSPACE.ORG
> security. But we won't get _truly_ secure programs until people can
> program securely; and people that can program securely can
> write secure
> programs in _any_ language.
This sounds suspiciously like an argument that has been going on in the
Linux-security mailing list. Basically the thrust of both arguments
are:
1) We can't secure the world.
2) Therefore we won't secure part of the world.
Sure we're going to have race conditions. Sure if you're klutzy enough
it's possible to have arbitrary commands executed via system(). It's
also possible to leverage root via a buffer overflow.
Would you argue that we shouldn't bother fixing race conditions because
there would still be buffer overflows out there to get us? It's
basically the same argument turned on its tail.
What I'm trying to get at, is that we, as a community, have to start
somewhere, and a bounds checking compiler (of any stripe, including C)
is a good place to start.
There will always be poor programmers out there so long as we don't
require authenticated IQ results with each software packages :).
Therefore, promoting tools that put some guardrails in place seems
prudent. If the guard rails are necessary in a portion of your program,
then use the disable-bounds-checking compiler directive for that portion
of your code by all means. But I'd personally feel better about OKing
any suid code in an audit if it was bounds checked.
Just my $.02 + GST.
Dale Babiy
