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.