On 04/10/2014 04:02 PM, Rahul Sundaram wrote:
Hi
On Thu, Apr 10, 2014 at 3:19 AM, Ian Malone wrote:
.
This bug was pretty bad, but the kind of mistakes that lead to
overflows and over-reads tend to be from not keeping track of the data
properly and will cause other problems anyway, memory protection
doesn't help with those.
In a managed language, it isn't typically possible to read past the
end of an array without it resulting in obvious errors. So while it
isn't a silver bullet, it could have helped significantly here to
notice the problem and correct the relevant related code.
Unfortunately C continues to dominate as a popular systems programming
language and these types of errors remain a frequent problem largely
because language level support for higher level abstractions remain
extremely weak. The fact that a major piece of extremely security
critical code received almost no support from commercial vendors for a
detailed audit for security flaws also remains a problem.
The cost of a "managed language" is that it affects performance. There
are essentially 2 phases in language. The first is static. The language
is compiled, and the compiler attempts to prevent buffer overflows or
reading past the end of an array. FORTRAN has had this for over 50
years. The second is dynamic or during run time. Some languages have
this (mostly interpretive languages). There is code that exists for C
that also can prevent this. But, OpenSSL, and libc, and other run-time
libraries on Linux and Unix and even DLLs in that other OS need to
consider performance, or the lack of. But, I maintain that virtually any
language suitable for use in run-time libraries can be subverted. But if
we go lower, there are even bugs in the chips. Remember the Intel
floating point bug a few years ago.
But, since our underlying libraries are written in C and are going to be
that way for a bunch of years, we should start using, or mandating the
use of tools such as Valgrind and Rational Purify as a method of testing
the code. These help the programmer locate potential latent bugs. Not
sure about Valgrind, but Purify takes libraries into account.
--
Jerry Feldman <gaf(a)blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90