Does anyone have any specific pointers on how to write more secure
code in Common Lisp? For instance, with C/C++ programs you have to
be careful not to allow buffer overrun's to occur. But I can't see
how this could be a problem in Lisp.
So, is there an equivalent type of problem with Lisp? The only
thing I can think of is to be careful of code-injection type problems
where evaluating s-expressions from an untrusted source could be
harmful. But that's pretty obvious.
Are there a set of hard-won rules-of-thumb to help avoid specific
security issues?
Thanks for any info!
Steve
In article
<····································@q39g2000hsf.googlegroups.com>,
Steve-o <······@googlemail.com> wrote:
> Does anyone have any specific pointers on how to write more secure
> code in Common Lisp? For instance, with C/C++ programs you have to
> be careful not to allow buffer overrun's to occur. But I can't see
> how this could be a problem in Lisp.
Unless you set optimization parameters, which might disable array bounds
checking.
>
> So, is there an equivalent type of problem with Lisp? The only
> thing I can think of is to be careful of code-injection type problems
> where evaluating s-expressions from an untrusted source could be
> harmful. But that's pretty obvious.
Less obvious is that this can happen simply due to calling READ, because
of '#.'. So you need to set *READ-EVAL* to NIL.
>
> Are there a set of hard-won rules-of-thumb to help avoid specific
> security issues?
>
> Thanks for any info!
>
> Steve
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
So> So, is there an equivalent type of problem with Lisp? The only
So> thing I can think of is to be careful of code-injection type problems
So> where evaluating s-expressions from an untrusted source could be
So> harmful. But that's pretty obvious.
even w/o eval, people can make DoS attack interning too many symbols,
starving server's memory.
so doing READ is tricky
On 2008-01-31, Steve-o <······@googlemail.com> wrote:
> Does anyone have any specific pointers on how to write more secure
> code in Common Lisp? For instance, with C/C++ programs you have to
> be careful not to allow buffer overrun's to occur. But I can't see
> how this could be a problem in Lisp.
I suppose all secure programming issues are potentially there... No?
- Integer overflow (if you use fixnums, double-floats, or other
fixed-size numbers)
- SQL injection
- Cross site scripting, if it's a web application
- Although with (safety 1) you can't really crash the application,
you can have buffer overflows and also crash your Lisp image
with (safety0). So, maybe "not using (safety 0) for code that will
handle non-validated input" should be added to the list
(most people will tell you to not use (safety 0) at all)
- Race conditions
Just my 0.02
J.
JP> - Although with (safety 1) you can't really crash the application,
in theory. i'm afraid implementation might have bugs..
especially if they have fancy optimizing compiler and are actively
developed.
also you can crash stuff with FFI
On Thu, 31 Jan 2008 10:43:41 +0100, Jeronimo Pellegrini wrote:
> - Although with (safety 1) you can't really crash the application,
Sure you can: just put some bugs in your code. Forget to convert an
input string into a number somewhere, before doing some maths on it?
Easy, peasy.
Cheers,
--
Andrew
On 2008-01-31, Andrew Reilly <···············@areilly.bpc-users.org> wrote:
> On Thu, 31 Jan 2008 10:43:41 +0100, Jeronimo Pellegrini wrote:
>
>> - Although with (safety 1) you can't really crash the application,
>
> Sure you can: just put some bugs in your code. Forget to convert an
> input string into a number somewhere, before doing some maths on it?
> Easy, peasy.
Hm, yeash, sounds like fun.
So, not using (safety 0), plus being careful when using (coerce) and
other functions that would bypass type safety.
I think doing lots of automated testing helps too (with well-thought
tests).
J.
Den Thu, 31 Jan 2008 15:23:33 +0100 skrev Jeronimo Pellegrini:
>>> - Although with (safety 1) you can't really crash the application,
>>
>> Sure you can: just put some bugs in your code. Forget to convert an
>> input string into a number somewhere, before doing some maths on it?
>> Easy, peasy.
>
> Hm, yeash, sounds like fun.
> So, not using (safety 0), plus being careful when using (coerce) and
> other functions that would bypass type safety.
Coerce doesn't bypass type safety, quite the opposite. The bug here would
be calling an arithmetic function on a string (which results in TYPE-
ERROR), instead on of on a converted value of that string.
Cheers,
Maciej
On 2008-01-31, Maciej Katafiasz <········@gmail.com> wrote:
> Den Thu, 31 Jan 2008 15:23:33 +0100 skrev Jeronimo Pellegrini:
>
>>>> - Although with (safety 1) you can't really crash the application,
>>>
>>> Sure you can: just put some bugs in your code. Forget to convert an
>>> input string into a number somewhere, before doing some maths on it?
>>> Easy, peasy.
>>
>> Hm, yeash, sounds like fun.
>> So, not using (safety 0), plus being careful when using (coerce) and
>> other functions that would bypass type safety.
>
> Coerce doesn't bypass type safety, quite the opposite.
Ops, sorry. Right, coerce will give a value of exactly the type you
need...
J.
Andrew Reilly wrote:
> On Thu, 31 Jan 2008 10:43:41 +0100, Jeronimo Pellegrini wrote:
>
> > - Although with (safety 1) you can't really crash the application,
>
> Sure you can: just put some bugs in your code. Forget to convert an
> input string into a number somewhere, before doing some maths on it?
> Easy, peasy.
If a simple error crashes your application, you need a better setup.
If you begin your application with
(with-ltk (:debug :deploy)
...)
then try some nonsense like (/ "0" 10), the user will get a pop up
saying "an internal error has occured" with an "OK" button. When
they click it, the ABORT restart is invoked. If your application
hasn't shadowed it you'll get Ltk's, which will bring you back to
waiting for events from the user. "Okay," the user says to
themselves, "there's a bug in that button, maybe now would be a good
time to save my work." Not, "damn application keeps crashing."
Steve-o <······@googlemail.com> writes:
> The only
> thing I can think of is to be careful of code-injection type problems
> where evaluating s-expressions from an untrusted source could be
> harmful. But that's pretty obvious.
A little less obvious is that by using #. you can invoke the evaluator
simply by READing an expression. That is why it is wise to bind
*READ-EVAL* to NIL when reading expressions that you can't trust. That
inhibits the evaluation during reading that is normally triggered by the
#. construct.
*PRINT-CIRCLE* should also be used if you are reading structures, or
else you may end up with a circular structure that takes forever to
print. Circular structure can be introduced during reads of
S-expressions, and AFAIK you can't turn that part of the reader off:
#1=(A B . #1#)
--
Thomas A. Russ, USC/Information Sciences Institute
On 31 Led, 20:56, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> *PRINT-CIRCLE* should also be used if you are reading structures, or
> else you may end up with a circular structure that takes forever to
> print. Circular structure can be introduced during reads of
> S-expressions, and AFAIK you can't turn that part of the reader off:
>
> #1=(A B . #1#)
>
SET-DISPATCH-MACRO-CHARACTER does not help? In fact, sanitizing you
readtable as much as possible is probably suggested in general if you
want to READ insecure input.
Tomas
P� Fri, 01 Feb 2008 10:39:42 +0100, skrev Tomas Zellerin
<········@gmail.com>:
> On 31 Led, 20:56, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>> *PRINT-CIRCLE* should also be used if you are reading structures, or
>> �else you may end up with a circular structure that takes forever to
>> �print. �Circular structure can be introduced during reads of
>> �S-expressions, and AFAIK you can't turn that part of the reader off:
>>
>> � � �#1=(A B . #1#)
>>
>
> SET-DISPATCH-MACRO-CHARACTER does not help? In fact, sanitizing you
> readtable as much as possible is probably suggested in general if you
> want to READ insecure input.
>
> Tomas
I'd say neither option is good.
In general you should only accept valid input and reject everything that
isn't legal rather than trying (in vain mostly) to foresee which
situations will cause trouble.
When I read form data I read it into a string (fixed size to to avoid DOS
attacks) then I run a regexp on the string. cl-ppcre can also extract the
relevant bits of data for me and thus there is no need for read.
You can't do this for all cases, but I would think twice about using read
on any data you are not sure about.
--------------
John Thingstad