httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: 1.1.2 plan
Date Sun, 12 Jan 1997 01:24:59 GMT
What do people think of my updated directory index patch with the

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, 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.  

View raw message