Re: [Lit.] Buffer overruns

From: David Wagner (daw_at_taverner.cs.berkeley.edu)
Date: 01/23/05 

Date: Sun, 23 Jan 2005 20:50:41 +0000 (UTC)

Douglas A. Gwyn wrote:
>David Wagner wrote:
>> I buy that. If you can prove that your program is free of buffer
>> overrun bugs, then ABC is pretty pointless. But I think it is today
>> beyond the state of the art to get this far, if we are talking about
>> C code.
>
>You're still coming at it from the mindset that the code
>gets written any old whichway, then is checked for buffer
>overruns. What I have been advocating is that the code
>be developed in such a way that buffers cannot be overrun.

I don't think so. I agree that you can get a lot more leverage by
changing the way programs write programs, than by trying to clean up their
messes after the fact. I very much like the idea of developing C code
in such a way that buffers cannot be overrun, and in particular, in such
a way that it is trivial to verify after you're done coding that there
are no buffer overruns. The problem is, I don't know of any such way.
I don't know how to achieve this. I can't find anyone else who has been
able to tell me how to do it, either.

If I can convince you to show me some detailed discipline -- say a
coding discipline, or a combination of a coding and testing discipline,
or somesuch -- that makes it easy to verify after you're done that there
are no buffer overruns in your C code, I'd love to see it. I'd be happy
to be convinced that I'm wrong. If you could show me some evidence
that it is indeed possible to come up with such a discipline, I would
be overjoyed to see it. But I have yet to see any such evidence.

If you have insights on how to do this, please do show us the concrete
details. I would prefer that you were right and I was wrong.

>For example, all buffer operations can be done through a
>carefully designed and checked interface that simply does
>not access past allocated bounds.

At a high level, that's a good start, and I advocate such interfaces.
But I don't think it is anywhere near enough. For example, how about
pointer dereferences? What do you do to ensure that it is not necessary
to reason in detail about aliasing? Please show us the details.

Relevant Pages

  • Re: How to develop a random number generation device
    ... what is in the memory you've over run into. ... subject to the caveat that the term "buffer overrun" is normally used ... Exploitation requires the write to succeed, ...
    (sci.electronics.design)
  • Re: gets() is dead
    ... They are so fixated on avoiding the UB on buffer ... please enter only patient intials. ... If there is a possibility of sabotage and your system is so badly designed that it allows input data to be executed as code, then yes, any buffer overrun is vulnerable. ... No automatic tool can pick up calculation of the wrong value. ...
    (comp.lang.c)
  • Re: A very interesting book
    ... language is equally unsafe because there might be a buffer ... overrun. ... buffer overruns in a certain Interpreter. ... compile time. ...
    (comp.lang.c)
  • Re: Thorny Serial Comms "UART: Overrun" error Windows CE 5.0
    ... before starting to patch the serial driver I would try to ... > errorFlags has the OVERRUN bit set. ... >> Do you know if it's the UART's FIFO buffer or the Serial Driver's ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Thorny Serial Comms "UART: Overrun" error Windows CE 5.0
    ... in my case I am actually looping back from one COM port ... I don't know if it is the serial driver or the UART. ... errorFlags has the OVERRUN bit set. ... > Do you know if it's the UART's FIFO buffer or the Serial Driver's ...
    (microsoft.public.windowsce.platbuilder)
Quantcast