[pro] Heartbleed?

[Steve Haflich]

I agree with essentially everything in wglb's message, but (once again)
I'll grumpily jump in to emphasize a point which I think many on this list
have missed.


On Fri, Apr 25, 2014 at 1:20 PM, William Lederer
<william.lederer at gmail.com>wrote:

>
> I agree with the general sentiment that Lisp is a much safer language to
> build anything in. While several in this thread are pointing to bounds
> checking as one of the advantages that Lisp has over C and other languages,
> there is something else I find that is also very strong: It is easier to
> write programs about which a reader can reason about correctness. In Lisp,
> the programs tend to be closer to provable and errors are more evident. As
> in "obviously no deficiencies" vs "no obvious deficiencies".
>
> But in my experience, vulnerabilities result from
>
>    - Buffer Overflows/lack of bounds checking (Heartbleed and friends)
>    - Configuration errors
>    - Logic Flaws
>    - Dangerous use of user input (leading to SQLi, XSS, XSRF)
>    - Improper use of cryptography
>    - Unclear protocol specification (leading to OpenSSL)
>
> This (IMO entirely worthy and correct) summary can easily be
misunderstood!  Lisp may be superior because it has bounds checking. (We've
previously agreed that isn't guaranteed since it isn't in the ANS, and in
any platform likely depends on optimization qualities, including the
optimization qualities under which internal called routines were compiled.)
 But bugs based on buffer overflow don't on normal operating systems in
general involve bounds checking.  At some point on any modern OS, reading
or writing to a socket stream will involve passing to the OS (generally via
a thin user-mode C API layer like *nix read() and write(), or some socket
analogue).  Neither Lisp nor C will provide any automatic bounds checking
on such a call.  The OS treats the application's address space as a
mostly-contiguous undifferentiated sea of bytes(*).  It doesn't matter that
at the app level C also has this model of a sea of bytes, while in Lisp the
ocean is run-time tagged into small plots.  That distinction disappears
once one calls write(fd,buf,len).

The Lisp Machine in its several manifestations might be the only
counterexample, since there was no C boundary over which to cross, and
because type and bounds checking was performed for free in the microcode.
 But Lisp machines aren't around any more largely because of the economy of
scale.  The number of x86 and x64 processors on the planet must be nearly
on the order of 10^9, while the number of Lisp machine processors never got
out of the 10^5 range, so Intel and AMD etc. could justify huge investments
making those processors 3 orders of magnitude faster in raw speed.  Lisp
processors could not have kept up at bearable per-item cost.  Alas!

It is certainly true that the Heartbleed bug resulted from an
insufficiently-cautious implementation of an (overly?)complex
specification.  The author of the bug has essentially agreed with this
analysis.  But the "bounds checking" of most Lisp implementations would
provide no protection against this failure (about which the original
posting agrees) unless the succinctness and superior clarity of CL vs C
code might help it be seen.  That's a thin thread on which to hang an
entire language argument.

(*) I originally saw this beautiful metaphor, that C treats memory as an
undifferentiated sea of bytes, on some discussion list but can't remember
the originator.  Google shows current use scattered over many programming
subjects, but doesnt identify the original.  Anyway, it is the reason that
a small hyper-efficient C-struct-in-Lisp defining macro I wrote for a
certain huge CL software product is named "define-sea-struct" and (I used
to be a sailor) the operator for computing offsets possibly through
multiple levels of nested structs is called "following-sea".
 Paradoxically, http://www.ibiblio.org/hyperwar/NHC/fairwinds.htm says
"following seas" means "SAFE journey, good fortune" [emphasis added].
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20140427/93cd5d60/attachment.html>