Subject: Re: Using READ as an internet firewall [was Re: What case problem ...]
From: Erik Naggum <erik@naggum.net>
Date: 2000/11/14
Newsgroups: comp.lang.lisp
Message-ID: <3183202924198672@naggum.net>

* Kent M Pitman <pitman@world.std.com>
| It still leaves you in the position of having to utterly trust your
| vendor or to audit their code.

  I think it depends a little on how you collect the input.  I do not
  see a problem with collecting your own input, making sure it's sane,
  and then calling read.  I do see a problem with a protocol that uses
  read directly, as it has no control over when character consumption
  terminates.  A simple syntax error like omitting a closing delimiter
  could cause the reader to want to gobble up the rest of the input.

| Consider that many security breaches are said to come from data
| overruns in fixed-length strings during parsing that are exploited to
| write new program into interesting places.  Lisp's memory model is
| different, and that may make it harder to exploit such overruns, so
| that's good.

  A simple abuse of a naive implementation would simply transmit so much
  data to a Lisp process that it would consume all system memory.  There
  is no shortage of large and expensive objects that take little space
  in the data stream, like uninterned symbols, pathnames, etc.  This
  would be more of a denial of service attack, but blowing up the memory
  consumption of a Lisp process is quite serious if it's intended to run
  for a long time instead of die and restart all the time.

#:Erik
-- 
  ALGORITHM: a procedure for solving a mathematical problem in a finite
  number of steps that frequently involves repetition of an operation.
  ALGOREISM: a procedure for solving an electoral problem in a finite
  number of steps that frequently involves repetition of an operation.