[pro] Heartbleed?

[Steve Haflich]

There have been a lot of incorrect information and assumption on this
thread.  I'm not picking on Pascal here (because I know he knows better).

On Wed, Apr 23, 2014 at 11:39 AM, Pascal J. Bourguignon <
pjb at informatimago.com> wrote:
>
>
> and ask you to implement it only using the CL package, you won't be able
> to implement it in any CL implementation using non-zero safety, and you
> won't be able to implement it in most CL implementations using (safety 0).


In any case, you won't be able to implement an HTTP server in ANSI CL
because we of X3J13 didn't get around to defining any socket interface.  It
was a known need, but too difficult to achieve.  That's probably a good
thing, because any standard socket binding circa 1990 would likely have
been seriously incorrect and/or inadequate.  (Compare the lack of Unicode
binding.)

> This you could easily implement in CL, (as easily as in C), but again,
> while in C this is a heartbleed bug, in CL, it poses absolutely no
> security problem (unless you're using some certain implementations with
> (safety 0), which you should not have done anyways, you're really asking
> for problems, aren't you).

You're making unsupported assumptions about safety 0.  The ANS only makes
distinction between safety _3_ and safety anything else.  safety 3 is safe
code and in safe code certain user-code violations are required to be
signalled (usually where the ANS uses the word "should").  And there are
damn few of thos places.  Take for example aref, which might be used to
extract octets of characters or whatever from a buffer.  aref makes no
guarantees even in safe code that it will signal bad array bounds.

Of course, it is unlikely that a HTTP server would use aref in this
context, but more likely it would engage implementation-dependent socket
and/or stream extensions.  Do those extensions guarantee the kind of
paranoid safe checking?  Probably not, but even if they claim to do so, how
does one verify?  Real socket protocols use large buffers and simply pass
memory pointers and lengths AT the OS.  You might think that is bad
practice, but you might dislike the performance in a _real_ performance web
server that made too many guarantees.

(But I certainly agree that the Heatbleed bug results from a poor
implementation of an obscure specification.  But it isn't the language.)

> So it's not just the specifications, it's the language implementations
> that are at fault here (not the ANSI C language, which clearly says that
> it's undefined to read an uninitialized array or outside of allocated
> memory, and therefore you could expect as with any CL implementation to
> have exceptions signaled in such occurences (since it's undefined,
> implementation could define implementation specific exception
> mechanisms)).

"Consequences are undefined" ïs a term of art in the ANS.  Behavior might
range from DWIM to destruction of the Universe. You cannot expect a CL
implementation to check situations that are not specified by the ANS to be
checked.  I just checked the following form in SBCL and ACL -- both did
undefined things and did not signal errors.

(funcall (compile nil
           '(lambda (x)
              (declare (optimize (speed 3) (safety 0)))
              (svref x 10)))
         (make-array 3))

Just like C, but at least the Universe didn't disappear.  This time.

CL is not intrinsically more safe than C  How any favorite implementation
behaves is irrelevant to this argument.  It is the programmer that must
code safely.
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20140424/fd6165de/attachment.html>