[AOLSERVER] ANN: AOLserver 4.0.6 released

2004-07-16 Thread Dossy Shiobara


AOLserver 4.0.6 Released


On behalf of the AOLserver Team, I have the honor of announcing the
latest point release of AOLserver: 4.0.6.

This version is primarily a bug fix release following version 4.0.5.
A summary of changes is provided at the end of this document.


WHAT IS AOLSERVER?

AOLserver is America Online's Open-Source web server.  AOLserver is
the backbone of the largest and busiest production environments in
the world.  AOLserver is a multithreaded, Tcl-enabled web server
used for large scale, dynamic web sites.

Visit the project's website:

http://aolserver.com/


HOW CAN I GET AOLSERVER?

Download the source code from SourceForge:

http://aolserver.com/downloads/aolserver-4.0.6-src.tar.gz


I FOUND A BUG!  WHAT DO I DO?

File it in the Bug Tracker at SourceForge:

http://sourceforge.net/tracker/?group_id=3152&atid=103152


IS THERE A MAILING LIST?  WHERE'S THE USER COMMUNITY?

Yes!  There's an announcements-only and a general discussion mailing
list.  Instructions on how to subscribe are here:

http://aolserver.com/lists.php

There is also a wiki-web set up for AOLserver:

http://aolserver.com/wiki/


CHANGES SINCE LAST RELEASE?

Keepalive is enabled for response codes other than just 200 OK.

Change to make HTTP request "Host:" header mandatory for HTTP/1.1
connections by returning 400 Bad Request response.  Closes SF Bug
#787728.

Changed virtual server code to use the "hostname" param from the
"ns/module/nssock" section to map the default virtual server based
on the value (hostname) from the "ns/module/nssock/servers" section,
when the "Host:" header is either not specified (HTTP/1.0) or is not
found in the virtual server table.  Closes SF Bug #812036.

conn->headers can be NULL causing segfault.  Closes SF Bug #990439.

Define ENOTSUP on OpenBSD 3.5.  Closes SF Bug #985076.

Ns_GetMimeType() was returning defaultType instead of noextType if
the path contained a directory with a "." but the filename component
had no extension.  Closes SF Bug #739049.

Enable ADP/Tcl code to override Last-Modified: header from
ns_respond when -headers AND -file are specified.  Closes bug
#879076.

Lots of refactoring of ns_respond code to remove duplication.

ns_eval of script containing comments (i.e., lines starting with
"#") cause an error because $args is a list, which gets evaluated
differently than a plain string script.  Closes SF Bug #833940.

Ensure that supplementary groups from /etc/group are set if -u
username is specified, or dropped if a uid is specified so that the
nsd doesn't run with root's supplementary groups.  Closes SF Bug
#425401.

Trivial: eliminate one compiler warning.

Make the Tcl_Panic() message from Ns_TlsGet() and Ns_TlsSet()
include the full function name to aid in debugging.

Ensure synchronous signals are handled correctly under LinuxThreads.
Possible fix for SF Bug #982955.

Fix build on alpha arch, removing extra INT64 typedef.  Closes bug
#896962.

ns_log can now log to a custom logger as well.

Unnecessary test for data != NULL actually caused part of bug
#971016 when fastpath.cache=false and fastpath.mmap=true and the
file requested is zero bytes, mmap() returns 0 which gets passed
along as data == NULL, causing ReturnCharData() to not flush the
queued headers.  Removing the if is safe as Ns_WriteConn will simply
flush any queued data.

If nsend == 0, we would never call Ns_WriteConn to flush the queued
headers.  This could happen when we're sending zero bytes of data as
a response.  This fixes bug #971016 in the case where
fastpath.cache=false and fastpath.mmap=false and a zero byte file is
requested.

One-liner fix for sending Content-Length header for content of zero
bytes.  Closes SF Bug #971016.



--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  "He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.


[AOLSERVER] Security issue in Aolserver

2004-07-16 Thread Jade Rubick
There is a security issue in Aolserver, which is described here:
http://openacs.org/bugtracker/openacs/bug?bug_number=2011
Untrusted users can craft pages that subsequent users will receive when
they browse the site.
This should be a one-line bug-fix, I imagine.
Jade
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.


Re: [AOLSERVER] Security issue in Aolserver

2004-07-16 Thread Dossy
On 2004.07.16, Jade Rubick <[EMAIL PROTECTED]> wrote:
> There is a security issue in Aolserver, which is described here:
>
> http://openacs.org/bugtracker/openacs/bug?bug_number=2011
>
> Untrusted users can craft pages that subsequent users will receive when
> they browse the site.
>
> This should be a one-line bug-fix, I imagine.

This was discussed in the online chat, and my feelings are that there
are many, many places where AOLserver allows the developer to touch the
outgoing HTTP response headers.  It is the developer's responsibility to
sanitize any user-supplied input (or, potentially user-supplied input in
the case of the URL, or POST request body, etc.) to ensure that it's
valid.  In the case of request-supplied data that will be placed in an
HTTP response header, the developer should use code that checks for
embedded newlines in the data, to prevent these HTTP response splitting
attacks.

To change things like ns_returnredirect to only send up to the first
newline might be a "fix", but then you'd also have to guard uses of
"ns_set [ns_conn outputheaders] $key $value" where $value contains a
string with embedded newlines: how do you propose to "fix" that?

Lets discuss this issue, but my gut reaction is that the proper fix to
this issue is defensive programming by the application developer.  It
is likely not possible to completely enforce in the server alone.

-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  "He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.


Re: [AOLSERVER] Security issue in Aolserver

2004-07-16 Thread Bas Scheffers
> Lets discuss this issue, but my gut reaction is that the proper fix to
> this issue is defensive programming by the application developer.  It
I agree. What's next, sanity checking in the server against SQL attacks?
(ie: "some.adp?id=1; delete from users;")

The most common (only?) cause of hijackable applications is not sanity
checking input.

> is likely not possible to completely enforce in the server alone.
In any any case, AOLserver doesn't pretty to be a
shiny-happy-anyone-can-do-it-is-is-safe server like another Tcl based
product I found a major security flaw in!
(http://bas.scheffers.net/vgn-needs-login-exploit.html)

Just my 2 cents...

Bas.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.


Re: [AOLSERVER] Security issue in AOLserver (repsonse injection)

2004-07-16 Thread Dossy
The issue being discussed is the HTTP response injection described in
this paper:

http://www.sanctuminc.com/pdf/whitepaper_httpresponse.pdf

The idea is that there may be ways for user-supplied input to go,
unsanitized, into the HTTP response returned from the server.  This can
be used to send a faked HTTP response as part of the pipeline for HTTP
keep-alive connections.

Briefly:

Client makes two requests on the same connection via HTTP
keep-alive.

The server responds with what appears to be 3 responses to the 2
requests.

The first and third responses are the actual responses from the
server, while the second response is actually data from the first
response, using the weakness illustrated in the paper (refer to URL
above), splitting the HTTP response by being able to control the
data placed in a HTTP response header.


The HTTP/1.1 specification indicates that CRLF is an end-of-header
marker EXCEPT when followed by a continuation-line.  See the paragraph
about LWS:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html

Therefore, at the server level, when sending back "structured" HTTP
response headers (i.e., via "ns_returnredirect", or via "ns_set [ns_conn
outputheaders] key value") we can implement a check where:

if there is a CRLF sequence in the value portion of the header
and it is not followed by either an SP or an HT
then
truncate off the CRLF and everything following it
and send a message to the server log at Warning level about it.


This also raises the issue that AOLserver currently does NOT accept HTTP
requests where header lines are split across multiple lines via
header-continuation.  With regard to strict compliance to the spec.,
this is a bug and should be addressed separately.

I hope to have a fix and interim patch available for this by early next
week.  Does anyone have any issues with the proposed solution above?


-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  "He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.


[AOLSERVER] AOLserver 4.0.6 has crashing bug leading to DOS.

2004-07-16 Thread Stephen Deasey
How to reproduce:

> telnet host 80
> GET / HTTP/1.1
>


I sent an email about this early yesterday well before the release, but
didn't get any response.


Thanks.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.


Re: [AOLSERVER] AOLserver 4.0.6 has crashing bug leading to DOS.

2004-07-16 Thread Rob Crittenden
This causes a core dump?
rob
Stephen Deasey wrote:
How to reproduce:
> telnet host 80
> GET / HTTP/1.1
>
I sent an email about this early yesterday well before the release, but
didn't get any response.
Thanks.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.

--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.


Re: [AOLSERVER] Security issue in AOLserver (repsonse injection)

2004-07-16 Thread Dossy
I forgot to mention: HTTP responses that are ENTIRELY user-generated
(i.e., via "ns_write") will NOT be validated with this change.
Code which sends responses back via ns_write MUST validate its inputs
and ensure that the HTTP response it sends back is valid and conforms to
the spec. as necessary.


On 2004.07.16, Dossy <[EMAIL PROTECTED]> wrote:
> The issue being discussed is the HTTP response injection described in
> this paper:
>
> http://www.sanctuminc.com/pdf/whitepaper_httpresponse.pdf
>
> The idea is that there may be ways for user-supplied input to go,
> unsanitized, into the HTTP response returned from the server.  This can
> be used to send a faked HTTP response as part of the pipeline for HTTP
> keep-alive connections.
>
> Briefly:
>
> Client makes two requests on the same connection via HTTP
> keep-alive.
>
> The server responds with what appears to be 3 responses to the 2
> requests.
>
> The first and third responses are the actual responses from the
> server, while the second response is actually data from the first
> response, using the weakness illustrated in the paper (refer to URL
> above), splitting the HTTP response by being able to control the
> data placed in a HTTP response header.
>
>
> The HTTP/1.1 specification indicates that CRLF is an end-of-header
> marker EXCEPT when followed by a continuation-line.  See the paragraph
> about LWS:
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html
>
> Therefore, at the server level, when sending back "structured" HTTP
> response headers (i.e., via "ns_returnredirect", or via "ns_set [ns_conn
> outputheaders] key value") we can implement a check where:
>
> if there is a CRLF sequence in the value portion of the header
> and it is not followed by either an SP or an HT
> then
> truncate off the CRLF and everything following it
> and send a message to the server log at Warning level about it.
>
>
> This also raises the issue that AOLserver currently does NOT accept HTTP
> requests where header lines are split across multiple lines via
> header-continuation.  With regard to strict compliance to the spec.,
> this is a bug and should be addressed separately.
>
> I hope to have a fix and interim patch available for this by early next
> week.  Does anyone have any issues with the proposed solution above?

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  "He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.


Re: [AOLSERVER] AOLserver 4.0.6 has crashing bug leading to DOS.

2004-07-16 Thread Stephen Deasey
Line 1110 of driver.c:

sockPtr->reqPtr->request->method = "BAD";

request->method is usually a malloced string, but here it's pointing to
static storage.  After request is finnished Ns_FreeRequest is called on
the request pointer, which then tries to ns_free method.  The server
aborts at this point.






On Fri, 2004-07-16 at 13:22, Rob Crittenden wrote:
> This causes a core dump?
>
> rob
>
> Stephen Deasey wrote:
>
> > How to reproduce:
> >
> > > telnet host 80
> > > GET / HTTP/1.1
> > >
> >
> >
> > I sent an email about this early yesterday well before the release, but
> > didn't get any response.
> >
> >
> > Thanks.
> >
> >
> > --
> > AOLserver - http://www.aolserver.com/
> >
> > To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> 
> > with the
> > body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field 
> > of your email blank.
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with 
> the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field 
> of your email blank.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.


Re: [AOLSERVER] AOLserver 4.0.6 has crashing bug leading to DOS.

2004-07-16 Thread Dossy
On 2004.07.16, Stephen Deasey <[EMAIL PROTECTED]> wrote:
> How to reproduce:
>
> > telnet host 80
> > GET / HTTP/1.1
> >
>
> I sent an email about this early yesterday well before the release, but
> didn't get any response.

I don't know how I missed your email.  AUGH!  OK, this is fixed -- I
guess we'll be seeing a 4.0.7 release early next week!

That might be convenient, since it could also include the HTTP response
splitting fix as well.

-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  "He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.


Re: [AOLSERVER] Security issue in AOLserver (repsonse injection)

2004-07-16 Thread Stephen Deasey
On Fri, 2004-07-16 at 13:01, Dossy wrote:
> This also raises the issue that AOLserver currently does NOT accept HTTP
> requests where header lines are split across multiple lines via
> header-continuation.  With regard to strict compliance to the spec.,
> this is a bug and should be addressed separately.


I think this is already handled.  The comment for Ns_ParseHeader, which
is called within driver.c to parse the headers as they are recieved,
says:

Consume a header line, handling header continuation, placing
results in given set.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.


Re: [AOLSERVER] Security issue in AOLserver (repsonse injection)

2004-07-16 Thread Dossy
On 2004.07.16, Stephen Deasey <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-07-16 at 13:01, Dossy wrote:
> > This also raises the issue that AOLserver currently does NOT accept HTTP
> > requests where header lines are split across multiple lines via
> > header-continuation.  With regard to strict compliance to the spec.,
> > this is a bug and should be addressed separately.
>
>
> I think this is already handled.  The comment for Ns_ParseHeader, which
> is called within driver.c to parse the headers as they are recieved,
> says:
>
> Consume a header line, handling header continuation, placing
> results in given set.

I just tested with my own virtual server setup, and splitting the Host:
header on a continued line:

# telnet ... 80
...
GET / HTTP/1.1
Host:
 yyy:80

HTTP/1.0 200 OK
...

Suppose "xxx" is the default virtual server, and I requested "yyy" --
the response I got back was for server "xxx".  If I don't split the
Host: header and have it as all one line, it serves back the appropriate
page for server "yyy".

This might be an issue with the leading SP or HT not being trimmed
properly, or something else -- I'll have to investigate further.

-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  "He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.