Re: [Lit.] Buffer overruns
From: Hank Oredson (horedson_at_earthlink.net)
Date: 01/29/05
- Next message: Hank Oredson: "Re: [Lit.] Buffer overruns"
- Previous message: Bryan Olson: "Re: [Lit.] Buffer overruns"
- In reply to: David Wagner: "Re: [Lit.] Buffer overruns"
- Next in thread: BRG: "Re: [Lit.] Buffer overruns"
- Reply: BRG: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 29 Jan 2005 02:58:25 GMT
"David Wagner" <daw@taverner.cs.berkeley.edu> wrote in message
news:ctergj$jv7$2@agate.berkeley.edu...
> Hank Oredson wrote:
>>"David Wagner" <daw@taverner.cs.berkeley.edu> wrote:
>>> Hank Oredson wrote:
>>>>This is not a library or language issue.
>>>
>>> Yes, it is.[...]
>>> Perhaps you mean that it is not *solely* a library or
>>> language issue -- but that is a very different statement.
>>
>>Whatever. If the library does not suit your needs, get
>>a different library or create your own.
>
> Exchanges like this make me wonder whether we are even speaking the same
> language, because I am having a terribly hard time understanding what
> you are trying to say. You say it is not a library issue, but then you
> say I should get a different library. If it is not a library issue,
> why would you tell me to get a different library?
If you think the library in question does not suit your needs,
THEN you get another library, or you build one that DOES
suit your needs. There is nothing that forces the use of a bad
library ... except for incompetent programmers and managers.
> It sounds to me like you accept that it *is* partially a library
> issue, that a library *can* have an influence on the security of your
> system, and that your previous statement was wrong, but you don't
> want to come out and say it in that form. Am I misunderstanding?
Yes, you are misunderstanding.
>>> Yes, you can write buggy programs in any language. But some
>>> languages and libraries make it easier to avoid bugs, and to verify
>>> their absence. Some coding disciplines make it easier to avoid bugs,
>>> and to verify their absence.
>>
>>And your point is?
>
> My point is: You are wrong when you say it is not a language or library
> issue. You are wrong to use "you can use buggy programs in any language"
> as justification for the claim that it is not a language or library issue;
> that 'justification' does not support your claim.
A simple misunderstanding.
>>What I'm trying to say is that these problems all occur earlier in the
>>design cycle, during that choice of tools phase.
>
> Yes. I have been trying to say the same. Perhaps you have come in to
> the thread a bit late, and haven't seen some of we have written before?
I've read the whole thing. I lurk a lot. I'm retired, sometimes have
severe fatigue due to a medical problem. Then I read, but don't
have the energy to post.
> Anyway, to recap, I have been saying that choosing to write
> security-critical Internet-connected programs in C, with the C standard
> library, and without automatic bounds checking, is generally a case of
> choosing the wrong tools.
With those restrictions I agree. But who would do that?
Doing so would be bad design at the front of the project.
But I do not agree with your comment about bounds checking.
A long discussion of functions, modules and interfaces can be
avoided here I think, since bounds checking can be done
without respect to language or library. It's a design decision.
> This is not a religious war about someone's favorite language. This is
> a question of choosing the right tool for the job.
Then the one correct answer is assembler. Do NOT ever let
someone else get involved in the project. Write your own library.
Then and only then will you know for certain what you have.
In all other cases you must choose whether you trust the compiler,
trust the library, trust the linker, trust the program loader, trust the OS.
Are there better tools than C? Probably. But certainly C++ and
Pascal (claimed to be better tools than FORTRAN and COBOL)
did not work out very well. Perhaps ADA, but there is still the
problem of testing that the particular ADA compiler and library
you choose does not have some serious flaw lurking within it.
With C we at least know pretty well where the problems lie,
and can thus avoid them.
-- ... Hank http://home.earthlink.net/~horedson http://home.earthlink.net/~w0rli
- Next message: Hank Oredson: "Re: [Lit.] Buffer overruns"
- Previous message: Bryan Olson: "Re: [Lit.] Buffer overruns"
- In reply to: David Wagner: "Re: [Lit.] Buffer overruns"
- Next in thread: BRG: "Re: [Lit.] Buffer overruns"
- Reply: BRG: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
