Re: [Lit.] Buffer overruns
From: infobahn (infobahn_at_btinternet.com)
Date: 01/31/05
- Next message: Hank Oredson: "Re: [Lit.] Buffer overruns"
- Previous message: Paul Rubin: "Re: [Lit.] Buffer overruns"
- In reply to: Paul Rubin: "Re: [Lit.] Buffer overruns"
- Next in thread: David Wagner: "Re: [Lit.] Buffer overruns"
- Reply: David Wagner: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 31 Jan 2005 06:58:19 +0000 (UTC)
Paul Rubin wrote:
>
> infobahn <infobahn@btinternet.com> writes:
> > It might be a lot more to do with the fact that I am not privy to the
> > development environments of any large, internet-facing programs.
>
> Then perhaps your attitude would change if you had to deal with what
> those programmers are up against.
No, not really. I've worked with large programs before, in a variety
of environments - some good, some bad. And I've written networking
programs before, too. Some good, some bad. :-) The point is that
internet-facing isn't any different to non-internet-facing. You still
have input which you process to get output. If you let the input
(or, for that matter, the output) scribble over memory you don't
own, then YOU SCREWED UP.
Let's be careful out there.
<snip>
>
> > > Computer cycles are cheap these days.
> >
> > That's a sound engineering approach: "we don't know if our code works,
> > and we don't give tuppence about crappy response times, so let's stick
> > a monitor on every access and see if it howls". Nice one.
>
> Why stop with disabling ABC if cycles are so expensive? Why not write
> everything in assembler?
I'd love to, but it's not terribly portable.
In your position, I would now reply: "I'd love to disable ABC, but
it's not terribly secure".
To save time, I'll disagree right now on the security bit, okay?
> > After all, C is portable. If the program truly had no buffer
> > overruns, you could port the code to a system without ABC and yet
> > not suffer any risk that it might be exploited.
>
> How do I know that the program truly has no buffer overruns? All I
> can ever know is that it has none that I've detected.
That's precisely what I meant when I said that "you can't prove a
negative". God bless Usenet - off in some subthread, they're now
nattering about wheels and white crows and maroon elephants. But
this is what I *meant* - you can't know a program has /no/ buffer
overruns, in the general case. That doesn't mean you can't reduce
the likelihood to an arbitrarily low value with sufficiently robust
processes and sufficiently bright people.
> > > ABC changes buffer overrun bugs into out-of-bound exception bugs.
> >
> > If it modded the source code, I might even believe you.
>
> It changes the source code semantics, so that a[11] = 0 causes a
> trap instead of writing outside a buffer.
But if I move the source to another implementation, the change is
gone. Oops.
- Next message: Hank Oredson: "Re: [Lit.] Buffer overruns"
- Previous message: Paul Rubin: "Re: [Lit.] Buffer overruns"
- In reply to: Paul Rubin: "Re: [Lit.] Buffer overruns"
- Next in thread: David Wagner: "Re: [Lit.] Buffer overruns"
- Reply: David Wagner: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
