Re: Getting a number from a string

• Previous message: Pierre-François Gomez: "Re: SBCL + re-spawning, background swank server"
• In reply to: John Thingstad: "Re: Getting a number from a string"
• Next in thread: Frank A. Adrian: "Re: Getting a number from a string"
• Reply: Frank A. Adrian: "Re: Getting a number from a string"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Mon, 26 Apr 2004 06:16:34 -0800

> Date: Mon, 19 Apr 2004 11:45:08 +0100
(Sorry for delay in responding. I have a big queue of unanswered
newsgroup articles I've recently discovered. Tonight I've moved yours
up to the head of the list because this topic is urgent.)

> From: John Thingstad <john.thingstad@chello.no>
> Setting *read-eval* to nil eleminates the possibillty of running
> arbitrary code but your version is still suseptibe to DOS attacks.

I don't understand how that is possible. Please describe an environment
whereby somebody elsewhere on the net connects to my LISP server-level
appliation service and somehow denies other users of my service the
ability to use my service. Please convince me there's a real problem
I'm missing. See below for my arguent why it's impossible, and please
try to find a flaw in my arguent.

> Consider "(((((((((((((((((((((((((((((((((((((((...." until you run
> out of memory.

I don't run out of memory. The process running the service for that
specific user runs out of memory and crashes, which doesn't affect any
other users of my service. Or if I'm using mod_lisp (don't know if I
ever will because I don't know if it'll ever exist and be available on
my ISP) it might crash the shared server process, but I believe I can
protect against that problem easily, see below.

> To be absoluteley sure you must limit the length of the string you
> read to something reasonable.

If it's even a problem, that solution is trivial to implement.

> Also remember that read-error returns two values. If return is nil
> the second value is the error message. A normal approach is to log
> this. (multiple-value-setq and with-output-stream are your friends)

But I have to be careful to limit the size of the log, else a malicious
user could set up trojaned MS-Windows systems to flood my service with
illegal requests that make the log so huge that my total disk
allocation is exceeded, and then other users won't be able to use any
service that writes even one byte of temporary data to the disk.
Still, it's simple to limit the size of any particular file.
Still, such a problem should be in the security checklist.

Now the promised argument why there's no security problem (for me) in
the first place: All my proposed LISP WebServer applications use CGI.
The way it works is that:
(1) The user's client-program (browser) connects to my ISP's Web
server, issues a URL specifying one of my CGI applications. With the
GET method, the encoded HTML FORM is passed in the URL after the
question ark. With the POST method, the same data is passed by some
other mechanism on the side.
(2) My ISP's Web server reads all of the GET or POST data from the
user's client-program and stores it in a system buffer.
(3) My ISP's Web server passes a bunch of system/global variables to my
CGI application, one of which is the number of characters of client
data that have been buffered. In the case of the GET method, all that
data (up to 255 characters) is in a system variable. In the case of the
POST method, all that data is queued on standard input. (Note: If my
service immediately crashes to the read-eval-print debug loop, all that
encoded data will be passed to that debug loop, so I have to be careful
my program does (quit) at the first sign of trouble instead of entering
a debug loop already at this point.)
(4) My LISP/CGI application reads a system global to determine whether
the method is GET or POST, and checks the other system global for the
length to see whether it's too large to be reasonable, and then either
issues a brief failure message and does (quit), or reads into a LISP
string the entire contents of the encoded HTML FORM. At this point, all
user data is in that string, not in standard input, so the worst that
can happen from this point on if an unprotected error happens is that
the program goes into a break loop whereupon it tries to read from
standard input and sees EOF which causes an error which throws it into
a second level of break loop whereupon it tries to read from standard
input and sees EOF which causes ... infinite loop of spew back to the
user, but no way the user can pass any malicious data back to the
server during this particular HTTP connection.
(5) My LISP/CGI application performs decoding of the encoded HTML FORM
to yield an association list, each element of the form
(formFieldName . correspondingValue).
(6) My LISP/CGI application inspects specific eleents in that
association list to determine the identification of the user and the
current state of that user's process and the specific input data
supplied by the user, and proceeds with whatever the application needs
to do next for that user.

So if I make sure the size of the encoded HTML FORM is less than a few
megabytes, doing (quit) immediately if the length is too large, and my
application doesn't crash before exhausting standard input with the
POST method, and my application disables read-time evaluation when
reading s-expressions from any of the field values from the association
list, I don't see how a malicious user can compromise security via my
LISP/CGI application. What did I overlook?

• Previous message: Pierre-François Gomez: "Re: SBCL + re-spawning, background swank server"
• In reply to: John Thingstad: "Re: Getting a number from a string"
• Next in thread: Frank A. Adrian: "Re: Getting a number from a string"
• Reply: Frank A. Adrian: "Re: Getting a number from a string"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]