From ... From: Erik Naggum Subject: Re: Using READ as an internet firewall [was Re: What case problem ...] Date: 2000/11/14 Message-ID: <3183202924198672@naggum.net>#1/1 X-Deja-AN: 695660296 References: <86y9yrs8rd.fsf@piro.quadium.net> <86hf5bgxby.fsf@piro.quadium.net> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 974704621 28967 195.0.192.66 (20 Nov 2000 07:17:01 GMT) Organization: Naggum Software; vox: +47 800 35477; gsm: +47 93 256 360; fax: +47 93 270 868; http://naggum.no; http://naggum.net User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 Mime-Version: 1.0 NNTP-Posting-Date: 20 Nov 2000 07:17:01 GMT Newsgroups: comp.lang.lisp * Kent M Pitman | 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.