Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.lisp > #32760

Re: Buffer Overflow in LISP

Show all headers | View raw

yara.huss.113@gmail.com writes:

> Does the LISP language eliminate the buffer overflow attack problem?

This is not a question of language, strictly speaking.

By this I mean that both the ANSI Common Lisp Language Standard and the ISO C
Language Standard forbid buffer overflows, just like they forbid reading
uninitialized variables, etc.

But the way they forbid them is by specifying that the effect of such
actions are "implementation dependent" in the case of CL, or "undefined"
in the case of C.  Which practically means in both case, that it's up to
the implementation to decide what happens.

Notably, note that the C standard allows implementation to have run-time
handling of errors.

Furthermore in the case of CL, there's specified a SAFETY optimization
level, that let  you give an indication to the implementation on how
"safe" you want it the generated code to be, from 0 to 3.  Code compiled
with safety level 3 is called "safe code" (duh!), and has some
properties, but fundamentally, this doesn't change much. Spefically, it
doesn't impose the implementations to check bounds anymore than with
unsafe code.


So, both in the case of CL and of C, it's up to the implementation to
determine when, and if, bound checks are performed, and what would be
the consequences of an unbound access.

Now, it happens, for some strange social reasons, that the writers of
Common Lisp implementations will usually add run-time check, which will
signal run-time errors, and let the programmer handle them, while the
writers of C implementations will usually not include run-time checks,
and will blindly execute buffer overflows (unless the operating system
detects an invalid (unmapped) access and sends a SIGSEG or SIGBUS
signal).

But there's absolutely no reason why they should do that, from the
language specification point of view.


That said, one could conceive of a programming language that would
specify that invalid memory accesses be prevented in an implementation
independent way.

For example the programming language LSE (Langage Symbolic
d'Enseignement) specifies that using an invalid indice will produce a
run-time error, which will lead to the interruption of the program.
When running in an interactive environment, the user will then be able
to debug it (inspect the variables, modify them) and either stop or
continue the execution.  There is no uncertainty: this error detection
in LSE doesn't depend on the implementation, all LSE implementations
must detect those errors.


In conclusion, concerning Common Lisp, implementations will in general
detect out-of-bound accesses (and other errors), at run-time, notably
when the SAFETY optimization level is not 0; and some implementations
can also detect those error at compilation-time!


If you are concerned by buffer overflow errors, you should choose an
implementation that does detect such errors, and specify the compilation
options so it effectly does detect them.

In CL:

(declaim (optimize (safety 3) (debug 3) (speed 0) (space 0) (compilation-speed 0)))


In C, you could use gcc version 8, with the following options:

    gcc \
        -fsanitize=address \
        -fsanitize=null \
        -fsanitize=bounds \
        -fsanitize=vla-bound \
        -fsanitize=object-size \
        -fsanitize=unreachable \
        -fsanitize=shift \
        -fsanitize=shift-exponent \
        -fsanitize=shift-base \
        -fsanitize=integer-divide-by-zero \
        -fsanitize=signed-integer-overflow \
        -fsanitize=float-divide-by-zero \
        -fsanitize=float-cast-overflow \
        -fsanitize=nonnull-attribute \
        -fsanitize=returns-nonnull-attribute \
        -fsanitize=bool \
        -fsanitize=enum \
        -fsanitize-address-use-after-scope \
        -fsanitize-undefined-trap-on-error \
        -fstack-protector-all \
        -fstack-check \
        \
        -o pgm.o pgm.c


-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

Back to comp.lang.lisp | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Buffer Overflow in LISP yara.huss.113@gmail.com - 2019-04-25 03:52 -0700
  Re: Buffer Overflow in LISP shcv@sdf.org - 2019-04-25 09:21 -0400
  Re: Buffer Overflow in LISP "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-04-25 15:21 +0200
    Re: Buffer Overflow in LISP Barry Margolin <barmar@alum.mit.edu> - 2019-04-25 11:04 -0400
      Re: Buffer Overflow in LISP "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-04-25 19:22 +0200
        Re: Buffer Overflow in LISP Spiros Bousbouras <spibou@gmail.com> - 2019-04-28 08:34 +0000
          Re: Buffer Overflow in LISP Barry Margolin <barmar@alum.mit.edu> - 2019-04-29 12:31 -0400
        Re: Buffer Overflow in LISP a.daniel.eliason@gmail.com - 2019-05-23 08:35 -0700
          Re: Buffer Overflow in LISP Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-23 17:02 +0000
            Re: Buffer Overflow in LISP Stefan Monnier <monnier@iro.umontreal.ca> - 2019-05-30 15:50 -0400
          Re: Buffer Overflow in LISP "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-05-23 19:30 +0200
            Re: Buffer Overflow in LISP taruss@google.com - 2019-05-24 10:40 -0700
              Re: Buffer Overflow in LISP Paul Rubin <no.email@nospam.invalid> - 2019-05-24 10:45 -0700
                Re: Buffer Overflow in LISP "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-05-24 23:27 +0200
                [OT] was: Buffer Overflow in LISP Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-24 22:46 +0100
                Re: [OT] was: Buffer Overflow in LISP "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-05-25 01:00 +0200
                Re: [OT] was: Buffer Overflow in LISP Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-24 23:46 +0000
                Re: [OT] was: Buffer Overflow in LISP Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-25 01:35 +0100
                Re: Buffer Overflow in LISP Jason Cornez <jcornez@ravenpack.com> - 2019-05-29 16:10 +0200
                Re: Buffer Overflow in LISP "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-05-29 20:25 +0200
      Re: Buffer Overflow in LISP Vladimir Sedach <vsedach@oneofus.la> - 2019-09-22 21:26 -0700
        Re: Buffer Overflow in LISP Barry Margolin <barmar@alum.mit.edu> - 2019-09-23 00:45 -0400

csiph-web