RE: Buffer Overruns

[sean.kelly () lanston com]

> From: Crispin Cowan [mailto:crispin () cse ogi edu]
>
> I think Joseph got your point the first time, but you appear 
> to have missed his
> point.
>
> Yes, we all agree that languages that provide dynamic string 
> allocation and
> automatic garbage collection (e.g. Java) make it much easier 
> to write secure
> programs than languages that force you to do manual string 
> allocation and
> garbage management (e.g. C).  HOWEVER, *interpretive* 
> procedures like garbage
> collection cannot be written in themselves.  To implement the 
> lovely string
> allocation and garbage collection that Java provides, you 
> must write it in something other than Java.

Certainly.  I suppose I failed to cover this point exactly and for that I
apologize, but it was my hope that the programmers implementing the
interpreters or libraries for languages such as Java would have sufficient
skill to do it right.  I guess that they can never be fully relied upon, as
I've run into my share of library bugs, but the code to do dynamic memory
allocation is such that it would really take either a concerted effort or
extreme negligence to code it in such a way that it would be vulnerable to a
buffer overrun attack.  These are also errors that are often simple to
detect in testing before the code is shipped.  I would hope that such
cursory tests are being performed but I suppose it is too much to assume
they are (as history has proven).
 
> Joseph's point was that these features are written in 
> languages other than
> Java, usually C.  Many of Java's security problems have 
> resulted from C-style
> errors in the JVM, the Java Bytecode Verifier, or the Java compiler.

Yep.

> > Now, higher-level languages like Java, Javascript, VB, and 
> to some degree
> > C++ generally use string objects to store this data.
>
> C++ offers no security advantages over C.  The data typing 
> enforcement in
> C++ is far too loose to add any security value.  On the 
> contrary, the pervasive
> use of virtual functions in C++ just make it that much easier 
> to implement buffer overflow attacks.

IMO C++ is an extremely complicated language.  However, replacing char[1024]
buffers with string and similar alternatives (which I admit aren't required,
but at least they're available) should reduce the number of buffer
overrun-vulnerable code somewhat, simply because it's potentially
eliminating the single most common method for the attack.  While the point
you made above is absolutely correct, there is still a much greater
possibility of bugs in final programmer code than in library and interpreter
code, if only because the library and interpreter bugs are used by so many
more people and will be more likely to be found and fixed.

Regarding Savana's question... there is no good way to detect a buffer
overrun attack using a proxy or firewall because the packets being passed
are perefectly legitimate and acceptable.  The issue is that the information
being passed is specifically designed to exploit a weakness (a bug) in the
program the packets are being passed to.  It is possible, however, to reduce
the number of possible vulnerabilities by disallowing client-side scripting
like Javascript and ActiveX.


Sean