1.1.2 plan

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

So, Randy will put together 1.1.2 with the two security fixes and upload them.  

1) I suggest he provide them as both a tarball and as two patches so that
people with hacked installations can add them.

2) I also suggest we recommend two non-code fixes:
   a) compile without mod_cookies to fix the mod_cookies problem
   b) Turn DirectoryIndexing off (index.html will still be returned for
requests like "GET / HTTP/1.0", yes?), which can be configured per-dir,if
people don't want to muck with patching code.

3) I don't think we need to remove the binary distributions, but we might want
to consider adding a note about the warning to the listing in the binaries
directory, http://www.apache.org/dist/binaries.

4) Once all that is done, we can send a message to c.i.w.s.u and ap-announce
(to ap-announce first, though).  I propose something like the following.
To-be-determined comments in []'s.


###

Two security problems have been noticed in the Apache 1.1.1 code base. The
first is in mod_cookies, which is *not* compiled in the distribution by
default.  This hole allows outside users to attempt to scribble the memory
stack used by Apache, which could lead to the granting of shell access to an
outside user of the user-ID the httpd children run as.  The second hole is in
the way Apache handles very long URLs comprised of nothing but '/' characters -
the effect being that contents of directories may be viewable even if an
"index.html" file exists (or whatever DirectoryIndex is set to).

For this reason we are releasing an Apache 1.1.2, which contains patches for
these two holes.  The patches are also attached to this message, in a form
suitable for feeding the "patch" program from the "src" directory in the Apache
1.1.1 distribution.  There is also a way to prevent the security holes by
turning off two features, as explained below. 

Apache 1.2 betas appear to not have the most serious of the two holes, and we
are fixing the second hole for the next beta, due within the next week[?].

We strongly recommend users of Apache 1.1.1 do one of the following:

  1) download a copy of 1.1.2 from http://www.apache.org/dist/, compile and
     install it.
  2) apply the patches below to their 1.1.1 installations
  3) discontinue use of the cookie module and turn "directoryindexing" off.
  4) upgrade to a beta of 1.2

On a similar note, we are holding the next beta of 1.2 while we work on a
general solution to memory stack scribbling.


*More details on the security holes*

The following URL's describe each security hole more clearly:

[To be added]



*How to use the attached patches*

Attached to this message are two patches.  Save them into your "src"
subdirectory of your Apache installation, and then do the following:

  patch < cookies.patch
  patch < longurls.patch
  make

You should then have a new "httpd" executable.



*How to turn off the features*

With these changes you should not need to modify the 1.1.1 code.

  1) Recompile the server without mod_cookies.c.  If you're running the
     default set of modules, this is already left out.
  2) Turn off directory indexing by making sure none of your "Options"
     directives say either "Indexes" or "All".  


*Conclusion*

We would just like to conclude by saying that these holes have been discovered
not because Apache is necessarily more buggy than other servers, but because
source code is available to everyone, and thus it's easier to look for holes.
Very similar holes may exist in other commercial servers, but without source no
one outside the companies who own the code can know for sure, save for those
who are actively exploiting them.  

Thank you for using Apache.


Attached: cookies.patch, longurls.patch

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

Re: 1.1.2 plan

[Marc Slemko <ma...@znep.com>]

What do people think of my updated directory index patch with the
ifdef?

If there end up being lots of systems without ENOENT defined, having
some provisions for that in 1.1.2 could avoid the need for 1.1.3...

On Sat, 11 Jan 1997, Brian Behlendorf wrote:

> 
> Two security problems have been noticed in the Apache 1.1.1 code base. The
> first is in mod_cookies, which is *not* compiled in the distribution by

Perhaps something like "if you did not uncomment the mod_cookies line
in your Configuration, you are not at risk from this hole."

> default.  This hole allows outside users to attempt to scribble the memory
> stack used by Apache, which could lead to the granting of shell access to an
> outside user of the user-ID the httpd children run as.  The second hole is in
> the way Apache handles very long URLs comprised of nothing but '/' characters -
> the effect being that contents of directories may be viewable even if an
> "index.html" file exists (or whatever DirectoryIndex is set to).

^comprised of nothing but '/' characters^comprised of certain sequences
of characters

(it isn't just all '/'s, but also combinations of anything which will make
the path too long for stat, but will still allow the file to be found)

Perhaps also something about "this doesn't allow people to access
anything they couldn't before, but if you are depending on people not
knowing certain filenames it could cause a problem."

> For this reason we are releasing an Apache 1.1.2, which contains patches for
> these two holes.  The patches are also attached to this message, in a form
> suitable for feeding the "patch" program from the "src" directory in the Apache
> 1.1.1 distribution.  There is also a way to prevent the security holes by
> turning off two features, as explained below. 
> 
> Apache 1.2 betas appear to not have the most serious of the two holes, and we
> are fixing the second hole for the next beta, due within the next week[?].

Some of your lines are a bit long.

I would suggest something like:

	The mod_cookie hole is of a less serious nature in 1.2
	betas due to code changes, but the next beta of 1.2 will
	include fixes for these two reported problems.  The next
	1.2 beta will also include numerous other similar fixes
	which we have been working on for several weeks.

It doesn't sound too good to say "we don't think the hole is there,
but we are too stupid to know".  <g>

> We strongly recommend users of Apache 1.1.1 do one of the following:
> 
>   1) download a copy of 1.1.2 from http://www.apache.org/dist/, compile and
>      install it.
>   2) apply the patches below to their 1.1.1 installations
>   3) discontinue use of the cookie module and turn "directoryindexing" off.
>   4) upgrade to a beta of 1.2
> 
> On a similar note, we are holding the next beta of 1.2 while we work on a
> general solution to memory stack scribbling.
> 
> 
> *More details on the security holes*
> 
> The following URL's describe each security hole more clearly:
> 
> [To be added]

How much detail do we want to give?

Oh, and we should include thanks to the person putting out the
advisory for letting us know.  Not sure if we want to say anything
more about the fixes already being pending for the 1.2 tree before any
of this came up.

> 
> 
> 
> *How to use the attached patches*
> 
> Attached to this message are two patches.  Save them into your "src"
> subdirectory of your Apache installation, and then do the following:
> 
>   patch < cookies.patch
>   patch < longurls.patch
>   make
> 
> You should then have a new "httpd" executable.
> 
> 
> 
> *How to turn off the features*
> 
> With these changes you should not need to modify the 1.1.1 code.
> 
>   1) Recompile the server without mod_cookies.c.  If you're running the
>      default set of modules, this is already left out.
>   2) Turn off directory indexing by making sure none of your "Options"
>      directives say either "Indexes" or "All".  
> 
> 
> *Conclusion*
> 
> We would just like to conclude by saying that these holes have been discovered
> not because Apache is necessarily more buggy than other servers, but because
> source code is available to everyone, and thus it's easier to look for holes.
> Very similar holes may exist in other commercial servers, but without source no
> one outside the companies who own the code can know for sure, save for those
> who are actively exploiting them.