Re: [Lit.] Buffer overruns
From: Trevor L. Jackson, III (tlj3_at_comcast.net)
Date: 01/29/05
- Next message: David Wagner: "Re: [Lit.] Buffer overruns"
- Previous message: Bryan Olson: "Re: [Lit.] Buffer overruns"
- In reply to: infobahn: "Re: [Lit.] Buffer overruns"
- Next in thread: infobahn: "Re: [Lit.] Buffer overruns"
- Reply: infobahn: "Re: [Lit.] Buffer overruns"
- Reply: Douglas A. Gwyn: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 28 Jan 2005 18:29:15 -0500
infobahn wrote:
> David Wagner wrote:
>
>>infobahn wrote:
>>
>>>Not on this occasion. Security is of course important, but it is not
>>>the only consideration. The point I was trying to make is that a
>>>perfectly secure computer is unusable. We make trade-offs between
>>>security and convenience. I happen to think that security is important
>>>enough that I'm prepared to organise my code in a way that makes it
>>>much harder to find ways to attack it, but I don't think it's so
>>>important that I'm prepared to see the performance of every program
>>>drop through the floor.
>>
>>I understand that. But I'm not advocating perfect security.
>>I am advocating a reasonable minimum level of security. Buffer
>>overruns are unreasonable.
>
>
> I agree that buffer overruns are unreasonable. I do not agree that
> ABC solves the problem of buffer overruns. Firstly, it can cause
> performance degradation. Secondly, it doesn't address the root
> cause - sloppy programming practices.
I dispute your statement that the root cause of the problem is sloppy
programming. I suggest that the root cause is the complexity of
software and the contributing cause it the lack of effort for
eliminating excess complexity and managing the irredible complexity.
There's also a contextual contributor which is the goals of the
organization developing the software. If the software is to be sold and
the buyers cannot tell secure software from insecure software then any
attention paid to security is wasted.
>
> But the absence of ABC does not imply a priori that the program is
> insecure. If I want to add 10, 35 and 42, I can do so like this:
>
> #include <stdio.h>
> int main(void)
> {
> int n[] = { 10, 35, 42 };
> size_t max = sizeof n / sizeof n[0];
> size_t i = 0;
> int total = 0;
> while(i < max)
> {
> total += n[i++];
> }
> printf("%d\n", total);
> return 0;
> }
>
> This program is secure, EVEN THOUGH there is no ABC.
Is it? See Kernigan's paper on the use and misuse of symbolic constants,
particularly the newline character. The reason that paper is
interesting is that he showed that it would be impossible for a
programmer to detect the hidden "feature" by inspection of the source of
the application and the source of the compiler!
- Next message: David Wagner: "Re: [Lit.] Buffer overruns"
- Previous message: Bryan Olson: "Re: [Lit.] Buffer overruns"
- In reply to: infobahn: "Re: [Lit.] Buffer overruns"
- Next in thread: infobahn: "Re: [Lit.] Buffer overruns"
- Reply: infobahn: "Re: [Lit.] Buffer overruns"
- Reply: Douglas A. Gwyn: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]