Patches item #517267, was opened at 2002-02-13 16:23
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=303152&aid=517267&group_id=3152
Category: other
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Caruso (johnjcaruso)
Assigned to: Kriston Rehberg (kriston)
Summary: Patch for SEGV if 401 redirect is used
Initial Comment:
AOLserver 3.4.2 can generate a segmentation fault in
FreeUrl when it tries to dereference a NULL pointer.
This behavior happens ONLY if the server in question
has a 401 redirect specified, and it can only be
produced if a failure occurs in the Ns_ConnReadLine
routine (via rapid browser refreshes, for example).
Here's the relevant gdb output:
Program received signal SIGSEGV, Segmentation fault.
0x80798da in FreeUrl (request=0x0) at request.c:313
313 if (request->url != NULL) {
(gdb) bt
#0 0x80798da in FreeUrl (request=0x0) at request.c:313
#1 0x807986e in Ns_SetRequestUrl (request=0x0,
url=0x8174168 "/error_pages/401.html") at
request.c:286
#2 0x8077c75 in Ns_ConnRedirect (conn=0x81bc068,
url=0x8174168 "/error_pages/401.html") at op.c:231
#3 0x807af90 in ReturnRedirect (conn=0x81bc068,
status=401,
resultPtr=0xbefff864) at return.c:1206
#4 0x807a922 in Ns_ConnReturnBadRequest
(conn=0x81bc068,
reason=0x8128593 "Invalid HTTP request") at
return.c:838
#5 0x807e108 in ConnRun (connPtr=0x81bc068) at
serv.c:822
#6 0x807dc3a in NsConnThread (arg=0x81b3de8) at
serv.c:671
#7 0x811db42 in NsThreadMain (arg=0x81ffae0) at
thread.c:228
#8 0x4001ebb5 in pthread_start_thread
(arg=0xbefffe40) at manager.c:241
The problem stems from the fact that conn->request is
always NULL within ConnRun just before the following
code snippet is executed:
if (Ns_ConnReadLine(conn, &ds, &n) != NS_OK ||
(connPtr->request = Ns_ParseRequest
(ds.string)) == NULL) {
(void) Ns_ConnReturnBadRequest(conn, "Invalid
HTTP request");
goto done;
}
If Ns_ConnReadLine doesn't return NS_OK, conn->request
will remain NULL; Ns_ConnReturnBadRequest will then be
called, and it will in turn call ReturnRedirect(conn,
401, &result). If a 401 redirect exists, the calling
sequence shown above will be followed, and FreeUrl
(request) will eventually be called with
request==NULL, causing the SEGV.
I was able to reproduce this segmentation fault quite
easily on a VAlinux 6.2.3 system simply by doing VERY
rapid refreshes of a page (browser doesn't matter).
I've also verified that this behavior was present in
AOLserver 3.3.1 as well. The simplest workaround is
to remove the 401 redirect.
I created a patch for this problem which calls
Ns_ParseRequest within Ns_ConnRedirect to fill in the
conn->request structure if conn->request is NULL
(rather than calling Ns_SetRequestUrl, as the current
code does), and then also prevents the request from
being reauthorized if conn->request is still NULL.
Ns_ConnRedirect seemed to be the most logical point in
the call sequence where a URL was available to be used
to fill in the conn->request structure in this case.
This patch fixes the problem, but since I'm not aware
of all the internals of AOLserver, it may not be the
optimal approach. There's also still the underlying
problem that several routines (FreeUrl, SetUrl, and so
on) reference pointers without validating them first.
Hopefully the horrible formatting in this web form
corrects itself when the patch is submitted....
----------------------------------------------------------------------
>Comment By: John Caruso (johnjcaruso)
Date: 2002-03-20 10:47
Message:
Logged In: YES
user_id=452169
I'm not familiar enough with the code to give an informed
opinion, but while looking into this SEGV I found a number
of routines that dereference unvalidated pointers (FreeUrl,
SetUrl, Ns_ConnRedirect, Ns_ConnRead, and so on). My
client has been running AOLserver for several years and
hasn't run into any pointer deferencing problems until now,
though. I'd assume that most of the unvalidated references
aren't an issue because they always receive validated or
correct parameters from other routines; we just happened to
run into a major exception.
This particular problem is caused by such a simple set of
circumstances (having a 401 redirect and doing rapid
refreshes) that I'm surprised it hasn't been reported
before. In fact I did notice that the ArsDigita 3.2+ad10
patch level contains a fix for the same problem, so they
must have run into it as well. For details see:
http://www.arsdigita.com/aol3/DISTRIBUTION.txt
----------------------------------------------------------------------
Comment By: Kriston Rehberg (kriston)
Date: 2002-03-20 08:16
Message:
Logged In: YES
user_id=16427
How widespread would you say that the practice of
dereferencing unvalidated pointers is in AOLserver 3.x as a
whole?
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=303152&aid=517267&group_id=3152
