[pro] Heartbleed?

William Lederer william.lederer at gmail.com
Sat Apr 12 22:03:15 UTC 2014


I do software security professionally these days.

While it is easier (e.g., almost possible) to do memory corruption/buffer
overrun/stack smashing in any language, it is certainly far easier to do so
in C and C++.  Many languages these days link to C libraries, thus
increasing the possibility.

However, much of my work these days is done against .net applications,
which is a managed, garbage collected language. The number and frequency of
errors in the code is not smaller than with C.  It is still possible to get
remote code execution through the IIS/.net web stack.

Application security is very difficult, and not very many of us write
error-free code.

To me the issue with OpenSSL (and there are still some that remain,
although the ones that I know about are not as severe) is that the code is
very unclear and hard to reason about.  In fact, the best static code
analyzers had to be tweaked to see the issue.

Having many years experience in both C and C++, I find that working in Lisp
is much easier to make assertions about its fine-grained behavior, pretty
much agreeing with your experience.

I would like to rephrase the question: which language makes it easier to
reason about a large code base? My vote is for the Lisp family.  However,
keep in mind one of the best-written programs out there, Qmail, is written
in C. There is a lot to be said for who the author/authors are as well as
the language.

wglb


On Sat, Apr 12, 2014 at 4:52 PM, David McClain <dbm at refined-audiometrics.com
> wrote:

> Just curious for other opinions... but wouldn't this (Heartbleed) sort of
> buffer excess read-back failure have been prevented by utilizing a "safe"
> language like Lisp or SML?
>
> I used to be an "unsafe" language bigot -- having mastered C/C++ for many
> years, and actually producing C compilers for a living at one time. I felt
> there should be no barriers to me as master of my machine, and not the
> other way around.
>
> But today's software systems are so complex that it boggles the mind to
> keep track of everything needed. I found during my transition years that I
> could maintain code bases no larger than an absolute max of 500 KLOC, and
> that I actually started losing track of details around 100 KLOC. Making the
> transition to a higher level language like SML or Lisp enabled greater
> productivity within those limits for me.
>
> Dr. David McClain
> dbm at refined-audiometrics.com
>
>
>
>
> _______________________________________________
> pro mailing list
> pro at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/pro
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20140412/9657913e/attachment.html>


More information about the pro mailing list