more communications with the security note folks.

[Brian Behlendorf <br...@hyperreal.com>]

Note that the announcement will be going out on Monday.

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hyperreal.com     http://www.apache.org     http://www.organic.com/jobs

---------- Forwarded message ----------
Date: Sat, 11 Jan 1997 17:59:11 -0800 (PST)
From: Brian Behlendorf <br...@hyperreal.com>
To: Alfred Huger <ah...@secnet.com>
Cc: auscert@auscert.org.au
Subject: Re: Apache and Apache derivitive Web Servers

On Sat, 11 Jan 1997, Alfred Huger wrote:
> On Fri, 10 Jan 1997, Brian Behlendorf wrote:
> 
> > 
> > Thank you for the note.  If it's alright with you, we'd like to post a
> > message about this hole immediately to the apache-announce mailing list so
> > notify Apache users directly, and then after a few days post it on the web
> > site.  We have not received any reports of active abuse of this, and we're
> > glad it's no longer in 1.2, but we'd like to be as proactive as possible.
> > What do you think?
> 
> I think that's a great idea. In speaking with all the vendors and with the
> great response we have gotten, we will be posting on Monday.  

Great.  Is there a URL to your message we can give in ours?  What's the
best way to give information about this problem without preempting your
message?  We will be saying where the bug is and the possible impact
anyways, with full credit.

> > Also, you'll be happy to know we are delaying the release of 1.2 to
> > replace all occurances of "sprintf()" that handles user-supported data to
> > a portable version of "snprintf" to prevent similar problems, and have
> > looked at other security issues in Apache with a similar conservative eye.
> > We welcome any other input you might have however.
> 
> Taking care of sprintf is a fine idea, commonly people tend to replace it
> w/ snprintf however portability issues bother some people. What will you
> be doing?

Distributing our own snprintf(), probably borrowed from xinetd or
sendmail (depending on license issues), and having a HAVE_SNPRINTF()
#define for platforms which already have a (valid) version of it, which
appears to be surprisingly small.  We've been working on this for a few
weeks, so this hole certainly gives that effort more import now.  We'll
also probably do a psprintf() for our pool-based memory allocation system,
so static lengths for buffers can be reduced too.  

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hyperreal.com     http://www.apache.org     http://www.organic.com/jobs