Technical reasons to why Lisp is more secure than other languages.
Jules F. Grosse
written in Common Lisp is (supposed to be) inherently more secure
than, say, a program writte in C?
My concern is with programms connected to the Internet, and thus
subject to DoS, crashes, invasions, etc.
How does Lisp compare to other languages, like Smalltalk, Python,
Java, perl, C#, Erlang on this same subject?
Thank you for your answers.
jls
Christopher Browne
You should avail yourself of _Multics Security Evaluation:
Vulnerability Analysis_:
<http://csrc.nist.gov/publications/history/karg74.pdf>
And _Thirty Years Later: Lessons from the Multics Security Evaluation_:
<http://domino.watson.ibm.com/library/cyberdig.nsf/papers?SearchView&Query=(multics)
The bottom line, 30 years ago, was that Multics wasn't secure enough
for other than relatively benign environments.
It /was/ better than pretty much any of its successors due to using
string types that were inherently not vulnerable to buffer overflows,
the critical problem of C and its brethren.
The languages that you have mentioned as alternatives to C share,
along with PL/1 (the implementation language for Multics) and Ada (the
nearest 'modern' language to PL/1) that they have string types that
are much more strongly managed by compiler and runtime environment
than the strings used in C. Which has the massive benefit that
software written in any of these languages should suffer /far/ less
from issues of buffer overflows/buffer overruns than is the case for
software written in C and C++.
The comparison is that the differences, in this regard, between Lisp
and Smalltalk/Python/Java/.. will be relatively small, whereas the
difference between any of these and C/C++ is rather large.
Eliminating buffer overruns is only /one/ thing.
That doesn't eliminate DoS or any number of other such problems. It
is entirely possible (and likely!) for DoS vulnerabilities to be a
function of the design of a system's security policies and have
/nothing/ to do with the language used to implement the system.
--
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://cbbrowne.com/info/multiplexor.html
Rules of the Evil Overlord #55. "The deformed mutants and odd-ball
psychotics will have their place in my Legions of Terror. However
before I send them out on important covert missions that require tact
and subtlety, I will first see if there is anyone else equally
qualified who would attract less attention."
<http://www.eviloverlord.com/>
Tim Bradshaw
> Could someone please list me technical reasons in why a programm
> written in Common Lisp is (supposed to be) inherently more secure
> than, say, a program writte in C?
In default optimization conditions it is hard to get a buffer overflow
in Lisp (or in most implementations anyway). *Many* security bugs are
buffer overflow problems in C/C++ programs. Lisp further has
per-expression optimization setting via LOCALLY, so you can do
profile-driven optimization if you need to to ensure that *only* the
typically small amount of code which takes up most time is compiled
with unsafe compiler settings, and that that unsafe code can be found
by textual search through the source (on the assumption that the rest
of the code is compiled with safe settings). Thus:
(defun foo (x)
(declare (type string x))
...
(locally
;; This gets called really a lot according to the profiler
(declare (optimize speed (safety 0)))
(loop for i from 0 below (length x)
...)))
Or even better:
(defmacro with-unsafe-code (&body forms)
`(locally
(declare (optimize speed) (safety 0))
,@forms))
(defun foo (x)
...
(with-unsafe-code
...))
--tim
Gareth McCaughan
> Could someone please list me technical reasons in why a programm
> written in Common Lisp is (supposed to be) inherently more secure
> than, say, a program writte in C?
>
> My concern is with programms connected to the Internet, and thus
> subject to DoS, crashes, invasions, etc.
1. Programming in Lisp pretty much eliminates buffer overflows.
Lisp will complain if you try to write off the end of an array;
its string operations aren't designed in ways that encourage
you to try; the philosophy of the language is very much
"dynamic allocation, everywhere".
2. Lisp is strongly typed, whereas C is weakly typed. (Yes,
you read that right.) It's easier to cause chaos by persuading
a C program to treat some bogus bit pattern as a pointer
than it is in Lisp.
3. Lisp is a higher-level language than C, in that for most
applications it requires less attention to irrelevant trivia.
This frees up the bits of the programmer's brain that are
good at dealing with trivia for spotting important trivia.
4. Lisp provides good facilities for handling exceptional
situations. C provides longjmp (oww!) and basically nothing
else. So C programs that handle exceptional situations
correctly contain lots of boring code that checks return
values. It's very easy to miss a few.
Of course you can still write hideously insecure programs
in Lisp. For instance, if you think passing data that just
arrived over the net straight to a shell without scrubbing
and disinfecting it first, you deserve to lose and Lisp
won't stop you.
And having dynamic allocation everywhere may increase the
opportunities for DoS attacks -- maybe an attacker can
persuade your program to try to make lots of billion-character
strings.
> How does Lisp compare to other languages, like Smalltalk, Python,
> Java, perl, C#, Erlang on this same subject?
I don't know enough about Smalltalk, C# or Erlang to comment
usefully on them.
Python is, in the respects I listed above, much more like
Lisp than it is like C. It does everything dynamically,
checks for illegal array references, is strongly typed,
is a high-level language, and has decent exception handling.
(Not as sophisticated as Lisp's, but plenty good enough.)
It offers an unreliable module for "restricted execution",
which you shouldn't trust. (I forget what's wrong with it;
possibly many things.) Because it tends to run a lot slower
than Lisp, certain kinds of DoS attack may be more effective
against it.
Java is somewhere in between C and Lisp. It should be safe
from buffer overflows. It's strongly enough typed. (It has
casts, but they're much safer than in C.) It's not as full
of fiddly details as C, and its libraries can save you a
lot of effort, so I suppose it counts as "high-level"
even though the language itself is clearly weaker than
Lisp. Its exception-handling facilities are a bit painful
to use, but again they're good enough that you're likely
to escape Return Code Checking Hell. I'd naively guess
that Java implementations might have been subject to
quite a lot of security-minded code review, but you should
not believe that without investigating for yourself.
Perl doesn't have buffer overflow problems. It's decidedly
weakly typed in some weird respects; for instance, it will
happily treat a number as a string or vice versa. I'd guess
this opens up all sorts of exciting opportunities for
security bugs. I find that Perl requires too much
attention-to-the-irrelevant for me, but that may be
because I don't write very much of it. Experienced
Perl programmers probably find it nicely high-level.
Some features of Perl (e.g., regular expressions, which
are almost but not quite good enough for many tasks)
seem likely to encourage their users to go for not-quite-correct
solutions, which is scary when thinking about security.
Perl doesn't do exceptions, though you can sort of fake them
using eval or something.
Perl differs from the other languages discussed here in one
rather cool respect: it's the only one that actually *will*
(try to) protect you against passing dangerous stuff to
external programs, via its "tainting" mechanism. It marks
data that have come from untrusted sources, and complains
if you try to do risky things with them.
You probably know this already, but: There is no such
thing as a "secure" programming language. Your language
cannot hope to make sure your programs are secure,
unless it's so badly lobotomized that you can't do
anything useful with it at all. All you can hope for
is that the language won't open up new security holes
of its own, and won't actively encourage you to make
dangerous mistakes.
--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
Martin Simmons
news:slrnaqmodn.14v9....@g.local...
> 2. Lisp is strongly typed, whereas C is weakly typed. (Yes,
> you read that right.) It's easier to cause chaos by persuading
> a C program to treat some bogus bit pattern as a pointer
> than it is in Lisp.
The real issue here is run-time typing. Lisp is not a strongly-typed language
in the normal sense of the term, because the compiler doesn't enforce the type
of every value.
Even run-time typing is not a perfect solution, e.g. there is no string-specific
version of CONCATENATE, so accidentally concatenating a string to NIL will
quietly work, even though the NIL might indicate a programming error.
> Perl doesn't have buffer overflow problems.
Unfortunately that isn't true in practice: perl is implemented in C, so there is
plenty of scope for buffer overflow problems in the implementation.
--
Martin Simmons, Xanalys Software Tools
zne...@xanalys.com
rot13 to reply
Joe Marshall
> Lisp is not a strongly-typed language
> in the normal sense of the term, because the compiler doesn't enforce the type
> of every value.
Lisp is not *statically* typed. If you believe that Lisp is not
strongly typed, try taking the CDR of 0.
William D Clinger
usually means the combination of static typing and type safety. With
that definition,
C is statically typed but not strongly typed.
Common Lisp is neither statically typed nor strongly typed.
Most implementations of Common Lisp attempt to be type-safe,
provided all of the code is compiled at a sufficiently high
level of safety.
Will
Gareth McCaughan
[I wrote:]
> > 2. Lisp is strongly typed, whereas C is weakly typed. (Yes,
> > you read that right.) It's easier to cause chaos by persuading
> > a C program to treat some bogus bit pattern as a pointer
> > than it is in Lisp.
>
> The real issue here is run-time typing. Lisp is not a strongly-typed
> language in the normal sense of the term, because the compiler doesn't
> enforce the type of every value.
I think that's a bad sense of the term, since "statically
typed" is already available for it. I take "strongly typed"
to mean "you can't pass off a thing of one type as a thing
of another type". (Modulo appropriate remarks about subtypes,
etc.) Another term for this is "type-safe".
I see that Will Clinger says it's usual to take "strongly
typed" as meaning "statically typed and type-safe". Perhaps
I'd better change my terminology.
> Even run-time typing is not a perfect solution, e.g. there is no
> string-specific version of CONCATENATE, so accidentally concatenating a
> string to NIL will quietly work, even though the NIL might indicate a
> programming error.
Sure.
> > Perl doesn't have buffer overflow problems.
>
> Unfortunately that isn't true in practice: perl is implemented in C, so
> there is plenty of scope for buffer overflow problems in the implementation.
What I meant -- which I thought, perhaps wrongly, to be
clear in context -- was: Programs written in Perl don't
have the sort of buffer-overflow problems that programs
written in C have. Of course (1) the Perl interpreter
itself could have buffer overflows, and (2) bugs can
still result in trying to read or write off the end
of an array. Film at 11. :-)
Piers Cawley
> Perl doesn't do exceptions, though you can sort of fake them
> using eval or something.
Actually Perl's poorly named eval BLOCK construct *does* give you
proper exceptions, it's just that the syntax isn't quite what you'd
expect. The Error package even implements a try/catch/finally system
on top of that which works rather neatly. But it's definitely a
kludge, which is why Larry's come up with a new exception system for
Perl 6 that's much neater (whilst still looking weird, but hey, it's
Perl).
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Pascal Costanza
> Within the programming languages research community, "strong typing"
> usually means the combination of static typing and type safety.
Some time ago, I have made an extensive research on this issue, with
regard to definition of terms in the type system community. I have only
found one paper that actually has tried to give consistent definitions,
it is "Type Systems" by Luca Cardelli. (see
http://www.luca.demon.co.uk/Bibliography.html#Type systems - sorry the
anchor has a space in it)
Here's a short summary:
* Type safety means no core dumps. So any language can be regarded as
type safe that guarantees that no core dumps are produced at runtime.
This includes languages like Smalltalk and Common Lisp (without certain
optimization declarations).
* Type sound means anything that the programming language designer wants
it to mean. So for example, the Java language specification states that
a variable of a class or interface type guarantees to produce no
"message not understood" errors when message of the respective class or
interface type are sent to that variable. There was a debate in the
early days of Java if the language really holds this guarantee, and
there were even some minor modifications made to the JVM in some
releases after JDK 1.0 in order to guarantee type soundness. However,
for example Smalltalk states that any variable can receive any message,
but throws "message not understood" at runtime. You can easily guarantee
that this is really the case, so Smalltalk is _by definition_ type
sound! (I personally asked Luca Cardelli if this is a correct
interpretation, and he confirmed it.
* Static type checking means that (a certain amount of) type checking is
done at compile-time.
* Dynamic type checking means that (a certain amount of) type checking
is done at runtime. (BTW, no language can perform all type checks at
compile time, there must always be a certain amount of dynamic type
checking.)
* Weak typing means that the language allows for certain exceptions to
their general typing rules.
* Strong typing means that the language disallows any exceptions to
their typing rules.
This would make Common Lisp a type safe and type sound language that
relies purely on dynamic type checking. It would be a weakly typed
language, because of the facilities for declaration of certain kinds of
"unsafe" optimizations, but strongly typed by default.
Java would be a type safe and type sound language that relies partly on
static type checking. It would be a strongly typed language.
I think these definitions make sense - but I would definitely be
interested in hearing about other reasonable definitions of terms, with
pointers to the respective literature.
Pascal
--
Given any rule, however ‘fundamental’ or ‘necessary’ for science, there
are always circumstances when it is advisable not only to ignore the
rule, but to adopt its opposite. - Paul Feyerabend
Will Deakin
> * Type safety means no core dumps. So any language can be regarded as
> type safe that guarantees that no core dumps are produced at runtime.
> This includes languages like Smalltalk and Common Lisp (without certain
> optimization declarations).
>
> Java would be a type safe and type sound language that relies partly on
> static type checking. It would be a strongly typed language.
into contact with a number of java and comon lisp production systems and
believe that type safety means no core dumps.
AFAIK there have been no core dumps with the common lisp based system in
its operation over that last four plus years. However, there is about a
core a day from one or other of the deployed java systems and this has
peaked at about one-an-hour for a couple of days. (sigh).
:)w
Will Deakin
> * Type safety means no core dumps. So any language can be regarded as
> type safe that guarantees that no core dumps are produced at runtime.
> This includes languages like Smalltalk and Common Lisp (without
> certain optimization declarations).
> languages...]
>
> on static type checking. It would be a strongly typed language.
into contact with a number of java and comon lisp production systems and
Will Deakin
failed.)
Martin Simmons
news:aoko2c$c11$1...@paris.btinternet.com...
OK, but this is not a consequence of using tbe Common Lisp or Java languages
themselves. It is a problem with implemenation of the compiler or runtime
system.
Will Deakin
> OK, but this is not a consequence of using tbe Common Lisp or Java languages
> themselves. It is a problem with implemenation of the compiler or runtime
> system.
not stop all sorts of nasties such as core dumping. In fact I have
found that people can write java to core dump rather a lot.
:)w