Re: A way to prevent buffer overflow exploits?

Thomas Charles CONWAY wrote:


> ObCompilers: Apart from someone's hacked version of gcc, what C
> compilers will insert array bounds checking for you?


> [I think that Centerline's tools did that, but I don't know what's become
> of them now that Centerline is kaput. -John]


I believe that Steve Kaufer (one of the founders) obtained the rights
to all that technology. I worked on one of those tools; it was pretty
sick what it had to do to get code checked fast, but if you didn't
look behind the curtain (and didn't spend too much time thinking about
how you could get the same level of checking *all the time* at vastly
reduced performance penalty in Modula-3), it was impressive.


For reference, it checked:


    C++ style rules (those Eff. C++ rules that were easy
    to check mechanically).


    One definition rule for C and C++, with helpful
    attempts to explain what had gone wrong.


    Array bounds (for all arrays, including stack and
    embedded within structures).


    Type casts (for variables on stack, statics, globals,
    and many instances of heap variables, using some not-
    too-clever inference rules from malloc idioms; C++
    was easier, except for placement new).


    Malloc/free new/delete new[]/delete[] matching.


    Reference to dangling stack variables,
    use of uninit memory.


    Compatible with partially instrumented code.


    All-singing-all-dancing diagnostic suppression.


    (Efficiently) tolerant of threads and dynamically
    loaded libraries.


There were some things that were just blessedly hard to get right.
Because it worked source-to-source and not source-to-object there were
some things that just couldn't be said in C++ and we had to punt.


And, after working on that, and trying it out on all the code we could
get our hands on, I concluded that only gzip was not buggy; everything
else contained latent bugs of varying severity.


There are some other similar products out there. Parasoft sold
something that was lots (2x) slower and checked different things (only
used declared sizes for checking bounds, didn't check types, did some
interesting on-the-fly leak detection that I think was the major
source of their lack of speed).


But, of course, now I'd tell you to just work in Java; there'll be
good compilers for it soon enough. If you're too impatient for RSN
performance, work in Modula-3, it's there now (and has been for years,
not that that matters at all).


David Chase
NaturalBridge LLC
--

Return to the comp.compilers page.
Search the comp.compilers archives again.