[pro] Heartbleed?

Fri Apr 25 20:20:10 UTC 2014

Team:

I would like to weigh in here as a security professional who uses Lisp in
daily practice.  I do Application Security assessments and advise companies
on secure coding practices. I do penetration tests and have discovered a
zero day in OpenSSL (not anywhere near the severity of Heartbleed.)

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)

So while I would recommend to anyone who will listen to use Lisp (and
likely to many who won't) as the base of their application, I would also
caution them to not take their eye of the other likely sources of
catastrophic application failure.

Finally, one of the most famous positive security stories is Qmail, which
handles a significant fraction of all internet mail.  It is written in C
and has been in use for a very long time.

Thus, I feel Lisp is better but not a total panacea.  For example, has the
Ironclad library been examined by a cryptographer? Does it, for example, do
constant-time comparisons to avoid timing leaks?

wglb

On Fri, Apr 25, 2014 at 2:56 PM, Scott L. Burson <Scott at sympoiesis.com>wrote:

> On Thu, Apr 24, 2014 at 11:44 PM, Steve Haflich <shaflich at gmail.com>
> wrote:
> >
> > On Thu, Apr 24, 2014 at 10:35 PM, Jean-Claude Beaudoin
> > <jean.claude.beaudoin at gmail.com> wrote:
> >>
> >> On Fri, Apr 25, 2014 at 12:31 AM, Scott L. Burson <Scott at sympoiesis.com
> >
> >> wrote:
> >>>
> >>> I've long thought that was an oversight, though now that you point it
> >>> out, I realize I must have been mistaken.
> >
> > "Oversight" might be the wrong way of thinking about this. [...]
> >  We changed what _needed_ to be changed, cleaned
> > up a lot of other inelegances, but there was not time or energy to
> attempt a
> > thorough job.  [...]
>
> All I mean by "oversight" is that it was not the product of a
> deliberate decision.  From the tone of your previous message I thought
> that it must have been deliberate, but now it sounds like I was
> probably right the first time, though we don't know for sure.
>
> >>> Still, it surprises me.  I don't know of any implementation that
> >>> doesn't bounds-check aref under normal speed/safety settings, and
> >>> clearly, users expect them to do so.
> >>
> >> I am surprised too. I always understood it like you Scott but now that
> >> re-read
> >> the page on aref I see that it is exactly like Steve says, no mention of
> >> any
> >> exception and a statement that "subscripts" must be a list of valid
> array
> >> indices
> >> right from the start of the call to aref. Yet that leaves me even more
> >> curious
> >> to know which implementation has read the spec as strictly as Steve says
> >> it can be even under (safety 3)? Does anyone know any?
> >
> > I don't know of any and there might not be any, at least among main-line
> > implementations.   [...]
> >
> > But in your paragraph above I'm bothered by its hidden assumption: It
> > suggests that after the ANS was available sneaky implementors studied it
> > kabalistically to find places where annoying error checks could be
> removed.
>
> I don't read Jean-Claude this way.  I think he was expressing surprise
> at the thought that an implementor might have done that.
>
> > To return to my important point, the language of the ANS wont let you
> read
> > or write from a socket.  At some point user application code will have to
> > call some non-ANS functions, and in the real world those functions (just
> > like C) will take a pointer into some overlarge buffer array along with a
> > length, and that memory location will be passed further down to some
> system
> > code (likely written in C) that has access to the entire user-space
> memory.
> > Now, without the missing check on the length that allowed the Heartbleed
> > bug, such an error won't allow buffer overruns in either input or output,
> > but my point is that user C code and user CL code are little different in
> > this regard.
>
> It certainly is _possible_ to write an unsafe socket-write function
> (*) in a CL library.  But I still think the _probability_ of someone
> doing so is substantially smaller in CL than in C.  Writing in C is
> like putting
>
>   (declaim (optimize (speed 3) (safety 0)))      ; damn the torpedoes!!
>
> at the top of every source file.
>
> When writing a safety-0 function in CL, the unsafe region is much more
> restricted, and one is more likely to be careful to add explicit
> bounds checks where appropriate.  (I recall only one occasion in my
> career where I forgot to do this.  Koff koff... but the point is, it's
> not an error one has the opportunity to make very often.)
>
> -- Scott
>
> (* Actually the missing bounds check was on a 'memcpy' call that was
> being used to prepare the heartbeat reply message, but the effect is
> the same as if it had been on the socket write.)
>
> _______________________________________________
> 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/20140425/e0f2bac6/attachment.html>