
		Stronghold Reference Site

Stronghold Web Server 3 known bugs

Bugs in Stronghold Web Server 3.0 build 3013

Versions of mod_rewrite prior to 1.3.14 have a security problem that may allow an attacker to download any file on your server; Stronghold Web Server build 3013 includes the patch for mod_rewrite, however the fix for the security problem breaks most configurations that use RewriteMap. This patch from the Apache Group fixes that problem.
Using SSLOptions +CompatEnvVars causes additional use of CPU time. This can be avoided by using only the new environment variables offered by mod_ssl, through specifying SSLOptions +StdEnvVars.
When proxying to a remote server using SSL, if verification of a client or server certificate fails the user is given a "Document contains no data" proxy error. The logs, however, contain the correct information.

Bugs in Stronghold Web Server 3.0 build 3012

Using SSLOptions +CompatEnvVars causes additional use of CPU time. This can be avoided by using only the new environment variables offered by mod_ssl, through specifying SSLOptions +StdEnvVars.
When proxying to a remote server using SSL, if verification of a client or server certificate fails the user is given a "Document contains no data" proxy error. The logs, however, contain the correct information.
All versions of mod_rewrite prior to the release of Apache 1.3.14 contain a security hole which, under a few configurations, can enable attackers to read any file on the system. Please also see Apache Week for additional information on the problem.

Bugs in Stronghold Web Server 3.0 build 3011

Using SSLOptions +CompatEnvVars causes additional use of CPU time. This can be avoided by using only the new environment variables offered by mod_ssl, through specifying SSLOptions +StdEnvVars.
When proxying to a remote server using SSL, if verification of a client or server certificate fails the user is given a "Document contains no data" proxy error. The logs, however, contain the correct information.
FreeBSD and some other systems have a built in limit on the size of the #! line for scripts such as apxs. For apxs to work with the provided copy of perl, it has been necessary to inform perl of where to look for the files evaluated by the use constructs used in apxs. However, including the two -I parameters might overrun this kernel-imposed limit of the #! line (64 characters in FreeBSD) and cause apxs to fail to execute correctly. The solution in this case is to remove the two -I parameters along with the associated paths and insert the following command in the bin/apxs script:
```
BEGIN
{
    push @INC,
        "<ServerRoot>/perl/lib",
        "<ServerRoot>/perl/site";
}
```
When building third party modules using APXS, the embedded perl call may not be correctly configured for the include paths. A fix is to modify bin/apxs to include -I<ServerRoot>/perl/lib -I<ServerRoot>/perl/lib/site as follows:
```
my $CFG_CFLAGS = 
    q(... `<ServerRoot>/perl/bin/perl
<ServerRoot>/perl/lib
<ServerRoot>/perl/lib/site -MExtUtils::Embed
       -e ccopts`); 
     
```