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