Re: [Lit.] Buffer overruns
From: Douglas A. Gwyn (DAGwyn_at_null.net)
Date: 12/29/04
- Next message: Paul Rubin: "Re: [Lit.] Buffer overruns"
- Previous message: Douglas A. Gwyn: "Re: code cracking or how do you know you've got the correct key?"
- In reply to: Paul Rubin: "Re: [Lit.] Buffer overruns"
- Next in thread: Paul Rubin: "Re: [Lit.] Buffer overruns"
- Reply: Paul Rubin: "Re: [Lit.] Buffer overruns"
- Reply: David Wagner: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 29 Dec 2004 12:27:04 -0600
Paul Rubin wrote:
> "Douglas A. Gwyn" <DAGwyn@null.net> writes:
>>By my reasoning, anybody who switches word processors in the hope
>>that the new one's spelling checker will fix his horrible spelling
>>is likely to be deluding himself that he has fixed his spelling problem.
> But if the documents are used an environment where the slightest
> spelling error can result in a security failure with potentially
> catastrophic consequences, it would be uncautious for even the most
> careful writers to use a word processor without a spelling checker.
I haven't been saying that a safety net isn't useful,
just that it doesn't get the job done.
> Using PL's without bounds checking in security applications is
> similarly uncautious, no matter how careful the programmer is.
There I disagree. The marginal utility of a tenth
safety net can be quite small when you already have
nine safety nets and a negligible chance of needing
any of them. If the right sort of care is taken in
the software development process, the circumstances
under which this particular safety net would come
into play are already reduced to an insignificant
level, compared with other opportunties for trouble.
Surely you don't think that code like
byte_t in[80], out[80], key[20];
// ...
encrypt(in, out, 180, key, 20);
where the 180 is the buffer length, would pass any
competent code or security review. So why should the
very same mistake using variables instead of constants
pass such a review? The problem is the lack of a
competent review, not the PL.
Note: I wouldn't recommend such simplistic buffer
design anyway, but I'm keeping the example simple
to reduce how much has to be understood.
- Next message: Paul Rubin: "Re: [Lit.] Buffer overruns"
- Previous message: Douglas A. Gwyn: "Re: code cracking or how do you know you've got the correct key?"
- In reply to: Paul Rubin: "Re: [Lit.] Buffer overruns"
- Next in thread: Paul Rubin: "Re: [Lit.] Buffer overruns"
- Reply: Paul Rubin: "Re: [Lit.] Buffer overruns"
- Reply: David Wagner: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
