Bugtraq mailing list archives
Re: at the risk of another flamefest..
From: stagda () NCS COM (David Stagner)
Date: Tue, 16 Jul 1996 09:47:22 -0500
Mike Neuman writes:
To fan the flames a bit, I find it amazing that people are complaining that C is at fault for their lousy programming...
That's hardly what I said. What I'm saying is that the shortcomings of C means that programmers must use significantly more effort and skill to avoid security problems. Some of these are very subtle (like the problems with gets() bounds checking (or lack thereof)), and can only be learned through lots of experience. And we cannot realistically expect ALL our code to be written by programmers with extensive security experience. In my eyes, a lot of "lousy programming" is simply using the wrong tool for the job, and then having to do kludgy workarounds to make up for the shortcomings of the tools. Case in point: programmers shouldn't HAVE to explicitly bounds-check every array operation in order to avoid security problems. The language should be able to handle overflow on its own. Explicitly checking every operation introduces potential bugs, and is a clear violation of KISS. The first step to secure code is clean code. And the hoops we must jump through because of C's weak typing and crude memory management are the antithesis of clean code. If a programmer misses a non-obvious memory-related security problem through error or naivete, is this "lousy programming"? I don't think it's that simple.
In any case, to add yet another level of indirection to the above argument, Mr. Bradley is forgetting that Unix itself is written in C. As a result, perl may have no bound problems, and so will the resulting compiled perl code, but the operating system itself could still have problems (a la syslog() ). -Mike mcn () EnGarde com
Yep. No matter how carefully you choose a better language for security, you're still stuck with someone else's C code with all its risks.
Current thread:
- Re: at the risk of another flamefest.. Peter Jeremy (Jul 15)
- Re: at the risk of another flamefest.. David Stagner (Jul 15)
- identd hole? Brett L. Hawn (Jul 15)
- Re: identd hole? Rob Quinn (Jul 16)
- <Possible follow-ups>
- Re: at the risk of another flamefest.. Eugene Bradley (Jul 15)
- Re: at the risk of another flamefest.. Eugene Bradley (Jul 15)
- Re: at the risk of another flamefest.. Mike Neuman (Jul 15)
- Re: at the risk of another flamefest.. Brian Clapper (Jul 16)
- Re: at the risk of another flamefest.. David Miller (Jul 16)
- Re: at the risk of another flamefest.. David Stagner (Jul 16)
- [linux-security] sliplogin David Holland (Jul 16)
- Re: at the risk of another flamefest.. Steve \ (Jul 16)
- Re: at the risk of another flamefest.. Eugene Bradley (Jul 16)