Q1:
How do I set the file permissions of my server and document
roots?
Q2:
I'm running a server that provides a whole bunch of optional
features. Are any of them security risks?
Q3:
I hear that running the server as "root" is a bad idea.
Is this true?
Q4:
I want to share the same document tree between my ftp and
Web servers. Is there any problem with this idea?
Q5:
Can I make my site completely safe by running the server
in a "chroot" environment?
Q6:
My local network runs behind a firewall. Can I use it to
increase my Web site's security?
To maximize security, you should adopt a strict "need to know"
policy for both the document root (where HTML documents are
stored) and the server root (where log and configuration files
are kept). It's most important to get permissions right in
the server root because it is here that CGI scripts and the
sensitive contents of the log and configuration files are
kept.
You need to protect the server from the prying eyes of
both local and remote users. The simplest strategy is to
create a "www" user for the Web administration/webmaster
and a "www" group for all the users on your system who need
to author HTML documents. On Unix systems edit the /etc/passwd
file to make the server root the home directory for the
www user. Edit /etc/group to add all authors to the www
group.
The server root should be set up so that only the www
user can write to the configuration and log directories
and to their contents. It's up to you whether you want these
directories to also be readable by the www group. They should
_not_ be world readable. The cgi-bin directory and its contents
should be world executable and readable, but not writable
(if you trust them, you could give local web authors write
permission for this directory). Following are the permissions
for a sample server root:
drwxr-xr-x 5 www www 1024 Aug 8 00:01 cgi-bin/
drwxr-x--- 2 www www 1024 Jun 11 17:21 conf/
-rwx------ 1 www www 109674 May 8 23:58 httpd
drwxrwxr-x 2 www www 1024 Aug 8 00:01 htdocs/
drwxrwxr-x 2 www www 1024 Jun 3 21:15 icons/
drwxr-x--- 2 www www 1024 May 4 22:23 logs/
The document root has different requirements. All files
that you want to serve on the Internet must be readable
by the server while it is running under the permissions
of user "nobody". You'll also usually want local Web authors
to be able to add files to the document root freely. Therefore
you should make the document root directory and its subdirectories
owned by user and group "www", world readable, and group
writable:
drwxrwxr-x 3 www www 1024 Jul 1 03:54 contents
drwxrwxr-x 10 www www 1024 Aug 23 19:32 examples
-rw-rw-r-- 1 www www 1488 Jun 13 23:30 index.html
-rw-rw-r-- 1 lstein www 39294 Jun 11 23:00 resource_guide.html
Many servers allow you to restrict access to parts of
the document tree to Internet browsers with certain IP addresses
or to remote users who can provide a correct password (see
below). However, some Web administrators may be worried
about unauthorized _local_ users gaining access to restricted
documents present in the document root. This is a problem
when the document root is world readable.
One solution to this problem is to run the server as something
other than "nobody", for example as another unprivileged
user ID that belongs to the "www" group. You can now make
the restricted documents group- but not world-readable (don't
make them group-writable unless you want the server to be
able to overwrite its documents!). The documents can now
be protected for prying eyes both locally and globally.
Remember set the read and execute permissions for any restricted
server scripts as well.
The CERN server generalizes this solution by allowing
the server to execute under different user and group privileges
for each part of a restricted document tree. See the CERN
documentation for details on how to set this up.
If your server starts up as root but runs as
another user, then it's especially important that the
logs directory not be writable by the user that the server
runs as. For example, both the Netscape FastTrack and SuiteSpot
servers come with the logs directory writable by the user
that the server runs as (i.e. as "nobody" if you choose
the default configuration values). This can make the effect
of some CGI bugs much worse than they would normally be.
For example if a CGI bug enables a remote user to run arbitrary
commands on the server, then the remote user can also gain
root access to the server by exploiting the bug to replace
a log file with a symlink to /etc/passwd. When the server
restarts, the symlink will result in /etc/passwd being chown'd
to the server user. The remote user can now exploit the
CGI bug again to add an entry to /etc/passwd. The suggested
workaround is to change the ownership of the logs directory
so that it's not writable by the server user, and then create
empty log and pid files that are owned by the server user
(the server won't start up if it can't open these files.)
Although this solution is less than optimal, because it
allows crackers to tamper with the log files, it is much
better than the default configuration. This bug may also
be present in other commercial servers. (Thanks to Laura
Pearlman for this information.)
Yes. Many features that increase the convenience of using
and running the server also increase the chances of a security
breach. Here is a list of potentially dangerous features.
If you don't absolutely need them turn them off.
- Automatic directory listings
- Knowledge is power and the more the remote hacker can
figure out about your system the more chance for him to
find loopholes. The automatic directory listings that
the CERN, NCSA, Netscape, Apache, and other servers offer
are convenient, but have the potential to give the hacker
access to sensitive information. This information can
include: Emacs backup files containing the source code
to CGI scripts, source-code control logs, symbolic links
that you once created for your convenience and forgot
to remove, directories containing temporary files, etc.
Of course, turning off automatic directory listings
doesn't prevent people from fetching files whose names
they guess at. It also doesn't avoid the pitfall of
an automatic text keyword search program that inadvertently
adds the "hidden" file to its index. To be safe, you
should remove unwanted files from your document root
entirely.
- Symbolic link following
- Some servers allow you to extend the document tree
with symbolic links. This is convenient, but can lead
to security breaches when someone accidentally creates
a link to a sensitive area of the system, for example
/etc. A safer way to extend the directory tree is to include
an explicit entry in the server's configuration file (this
involves a PathAlias directive in NCSA-style servers,
and a Pass rule in the CERN server).
The NCSA and Apache servers allows you to turn symbolic
link following off completely. Another option allows
you to enable symbolic link following only if the owner
of the link matches the owner of the link's target (i.e.
you can compromise the security of a part of the document
tree that you own, but not someone else's part).
- Server side includes
- The "exec" form of server side includes are a major
security hole. Their use should be restricted to trusted
users or turned off completely. In NCSA httpd and Apache,
you can turn off the exec form of includes in a directory
by placing this statement in the appropriate directory
control section of access.conf:
Options IncludesNoExec
- User-maintained directories
- Allowing any user on the host system to add documents
to your Web site is a wonderfully democratic system. However,
you do have to trust your users not to open up security
holes. This can include their publishing files that contain
sensitive system information, as well as creating CGI
scripts, server side includes, or symbolic links that
open up security holes. Unless you really need this feature,
it's best to turn it off. When a user needs to create
a home page, it's probably best to give him his own piece
of the document root to work in, and to make sure that
he understands what he's doing. Whether home pages are
located in user's home directories or in a piece of the
document root, it's best to disallow server-side includes
and CGI scripts in this area.
This has been the source of some misunderstanding and disagreement
on the Net. Most servers are launched as root so that they
can open up the low numbered port 80 (the standard HTTP port)
and write to the log files. They then wait for an incoming
connection on port 80. As soon as they receive this connection,
they fork a child process to handle the request and go back
to listening. The child process, meanwhile, changes its effective
user ID to the user "nobody" and then proceeds to process
the remote request. All actions taken in response to the request,
such as executing CGI scripts or parsing server-side includes,
are done as the unprivileged "nobody" user.
This is not the scenario that people warn about when they
talk about "running the server as root". This warning is
about servers that have been configured to run their _child
processes_ as root, (e.g. by specifying "User root" in the
server configuration file). This is a whopping security
hole because every CGI script that gets launched with root
permissions will have access to every nook and cranny in
your system.
Some people will say that it's better not to start the
server as root at all, warning that we don't know what bugs
may lurk in the portion of the server code that controls
its behavior between the time it starts up and the time
it forks a child. This is quite true, although the source
code to all the public domain servers is freely available
and there don't _seem_ to be any bugs in these portions
of the code. Running the server as an ordinary unprivileged
user may be safer. Many sites launch the server as user
"nobody", "daemon" or "www". However you should be aware
of two potential problems with this approach:
- You won't be able to open port 80 (at least not on
Unix systems). You'll have to tell the server to listen
to another port, such as 8000 or 8080.
- You'll have to make the configuration files readable
by the same user ID you run the server under. This opens
up the possibility of an errant CGI script reading the
server configuration files. Similarly, you'll have to
make the log files both readable and writable by this
user ID, making it possible for a subverted server or
CGI script to alter the log. See the discussion of file
permissions above.
Many sites like to share directories between the FTP daemon
and the Web daemon. This is OK so long as there's no way that
a remote user can upload files that can later be read or executed
by the Web daemon.
Consider this scenario: the WWW server that has been configured
to execute any file ending with the extension ".cgi". Using
your ftp daemon, a remote hacker uploads a perl script to
your ftp site and gives it the .cgi extension. He then uses
his browser to request the newly-uploaded file from your
Web server. Bingo! he's fooled your system into executing
the commands of his choice.
You can overlap the ftp and Web server hierarchies, but
be sure to limit ftp uploads to an "incoming" directory
that can't be read by the "nobody" user.
You can't make your server completely safe, but you can increase
its security significantly in a Unix environment by running
it in a chroot environment. The chroot system command places
the server in a "silver bubble" in such a way that it can't
see any part of the file system beyond a directory tree that
you have set aside for it. The directory you designate becomes
the server's new root "/" directory. Anything above this directory
is inaccessible.
In order to run a server in a chroot environment, you
have to create a whole miniature root file system that contains
everything the server needs access to. This includes special
device files and shared libraries. You also need to adjust
all the path names in the server's configuration files so
that they are relative to the new root directory. To start
the server in this environment, place a shell script around
it that invokes the chroot command in this way:
chroot /path/to/new/root /server_root/httpd
Setting up the new root directory can be tricky and is beyond
the scope of this document. See the author's book (above),
for details. You should be aware that a chroot environment
is most effective when the new root directory is as barren
as possible. There shouldn't be any interpreters, shells,
or configuration files (including
/etc/passwd!)
in the new root directory. Unfortunately this means that CGI
scripts that rely on Perl or shells won't run in the chroot
environment. You can add these interpreters back in, but you
lose some of the benefits of chroot.
Also be aware that chroot only protects files; it's not
a panacea. It doesn't prevent hackers from breaking into
your system in other ways, such as grabbing system maps
from the NIS network information service, or playing games
with NFS.
You can use a firewall to enhance your site's security in
a number of ways. The most straightforward use of a firewall
is to create "internal site", one that is accessible only
to computers within your own local area network. If this is
what you want to do,then all you need to do is to place the
server INSIDE the firewall:
other hosts
\
server <-----> FIREWALL <------> OUTSIDE
/
other hosts
However, if you want to make the server available to the
rest of the world, you'll need to place it somewhere outside
the firewall. From the standpoint of security of your organization
as a whole, the safest place to put it is completely outside
the local area network:
other hosts
\
other hosts <----> FIREWALL <---> server <----> OUTSIDE
/
other hosts
This is called a "sacrificial lamb" configuration. The
server is at risk of being broken into, but at least when
it's broken into it doesn't breach the security of the inner
network.
It's _not_ a good idea to run the WWW server on the firewall
machine. Now any bug in the server will compromise the security
of the entire organization.
There are a number of variations on this basic setup,
including architectures that use paired "inner" and "outer"
servers to give the world access to public information while
giving the internal network access to private documents.
See the author's book for the gory details.
You can, but if you do this you are opening up a security
hole in the firewall. It's far better to make the server a
"sacrificial lamb" as described above. Some firewall architectures,
however, don't give you the option of placing the host outside
the firewall. In this case, you have no choice but to open
up a hole in the firewall. There are two options:
- If you are using a "screened host" type of firewall,
you can selectively allow the firewall to pass requests
for port 80 that are bound to or returning from the WWW
server machine. This has the effect of poking a small
hole in the dike through which the rest of the world can
send and receive requests to the WWW server machine.
- If you are using a "dual homed gateway" type of firewall,
you'll need to install a proxy on the firewall machine.
A proxy is a small program that can see both sides of
the firewall. Requests for information from the Web server
are intercepted by the proxy, forwarded to the server
machine, and the response forwarded back to the requester.
A small and reliable HTTP proxy is available from TIS
systems at:
ftp://ftp.tis.com/pub/firewalls/toolkit/
The CERN server can also be configured to act as a proxy.
I feel much less comfortable recommending it, however, because
it is a large and complex piece of software that may contain
unknown security holes.
More information about firewalls is available in the books
Firewalls and Internet Security
by William Cheswick and Steven Bellovin, and Building
Internet Firewalls by D. Brent Chapman and Elizabeth
D. Zwicky.
For Unix systems, the tripwire program periodically scans
your system and detects if any system files or programs have
been modified. It is available at
ftp://ftp.cerias.purdue.edu/pub/tools/unix/ids/tripwire/
You should also check your access and error log files
periodically for suspicious activity. Look for accesses
involving system commands such as "rm", "login", "/bin/sh"
and "perl", or extremely long lines in URL requests (the
former indicate an attempt to trick a CGI script into invoking
a system command; the latter an attempt to overrun a program's
input buffer). Also look for repeated unsuccessful attempts
to access a password protected document. These could be
symptomatic of someone trying to guess a password.
Windows NT Servers
Q9: Are there
any known security problems with the Netscape Communications
Server for NT?
Server-Side Include Source Code Vulnerable, June 25,
1998
Programmers at
San Diego Source,
the online news service of the
San Diego Daily Transcript
have discovered that by appending certain characters to the
end of the URL that refers to a server-side include file,
a remote user can recover the source code for the file, disclosing
proprietary information, copyrighted source code, and even
user names and passwords used to log into databases. In addition
to affecting server-side includes, this bug affects such popular
products as Allaire Cold Fusion, Microsoft Active Server Pages,
and PHP.
Details of the exploit have not been published, but you
can find a longer description in the original article at
http://www.sddt.com/files/library/98/06/25/tbc.html.
Netscape is reportedly working on a fix. Please visit the
Netscape site for
possible patches. If you use server-side includes, you are
urged to upgrade as soon as a patch becomes available.
O'Reilly's WebSite and WebSite Professional
servers are also vulnerable to this bug. Microsoft IIS
servers do not appear to be.
Back Door Access to Protected Files, January 8, 1998
Netscape Enterprise Server 3.0 and FastTrack 3.01 both contain
a bug that allows unauthorized remote users to fetch documents
that are protected by IP address and password. This bug affects
any file that does
not use the standard DOS 8.3 naming
convention. For example, if the document is named
somelongfile.htm,
then the unscrupulous user can ask for the file SOMEF~1.HTM,
which is the mangled DOS equivalent of the file name. Even
though the document may be password protected, this fetch
will succeed.
This bug is fixed in Enterprise Server 3.5.1 or higher
(see this
technical note). It is unclear whether there is a patch
available for the FastTrack server, however, which was still
at version 3.01 as of June 30, 1998.
The same bug is present in the Microsoft
IIS server. O'Reilly's WebSite Professional are reportedly
free of the problem
Perl CGI Scripts are Often Misconfigured, 1997
The Netscape server does not use the NT File Manager's associations
between file extensions and applications. Thus, even though
you may have associated the extension .pl with the perl interpreter,
perl scripts aren't recognized as such when placed in the
cgi-bin directory. Until very recently, a Netscape technical
note recommended placing perl.exe into cgi-bin and referring
to your scripts as
/cgi-bin/perl.exe?&my_script.pl.
Unfortunately this technique allows anyone on the Internet
to execute an arbitrary set of Perl commands on your server
by invoking such scripts as /cgi-bin/perl.exe?&-e+unlink+%3C*%3E
(when run, this URL removes every file in the server's current
directory). This is not a good idea. A current Netscape
technical note suggests encapsulating your Perl scripts
in a .bat file. However, because of a related problem with
batch scripts, this is no safer.
Because the EMWACS, Purveyor and WebSite NT servers all
use the File Manager extension associations, you can execute
perl scripts on these servers without placing perl.exe into
cgi-bin. They are safe from this bug.
DOS .bat files are Insecure,
February, 1996
Older versions the Netscape servers (both the
Netscape
Communications Server version 1.12 and the
Netscape
Commerce Server version 1.0) have two problems involving
the handling of CGI scripts. One of these problems is also
shared by the
WebSite Server.
Ian Redfern (redferni@logica.com)
has discovered that a similar hole exists in the processing
of CGI scripts implemented as .bat files. The following
is excerpted from his e-mail describing the problem:
Consider test.bat:
@echo off
echo Content-type: text/plain
echo
echo Hello World!
If this is called as "/cgi-bin/test.bat?&dir" you get the output
of the CGI program, followed by a directory listing.
It appears that the server is doing system("test.bat &dir") which
the command interpreter is handling (not unreasonably) in the
same way /bin/sh would - execute it, and if things go OK,
execute the dir command.
Q10: Are there
any known security problems with the O'Reilly WebSite server
for Windows NT/95?
Server-Side Include Source Code Vulnerable, June 25,
1998
Programmers at
San Diego Source,
the online news service of the
San Diego Daily Transcript
have discovered that by appending certain characters to the
end of the URL that refers to a server-side include file,
a remote user can recover the source code for the file, disclosing
proprietary information, copyrighted source code, and even
user names and passwords used to log into databases. In addition
to affecting server-side includes, this bug affects such popular
products as Allaire Cold Fusion, Microsoft Active Server Pages
(using a 3d party ASP interpreter), and PHP.
Details of the exploit have not been published, but you
can find a longer description in the original article at
http://www.sddt.com/files/library/98/06/25/tbc.html.
O'Reilly has announced that a fix will be available in
WebSite and WebSite Professional version 2.3. If you use
server-side includes, you should strongly consider upgrading.
Windows-based Netscape servers are also
vulnerable to this bug. Microsoft IIS servers do not appear
to be.
.BAT Scripts Vulnerable (1996)
WebSite versions 1.1b
and earlier have the same problem with
DOS
.bat files that Netscape does. However because WebSite
supports three different types of CGI scripting interfaces
(native Windows, Standard CGI for Perl scripts, and the rarely
used DOS .bat file interface), the recommended action is to
turn off the server's support for DOS CGI scripts. This will
not affect the server's ability to run Visual Basic, Perl,
or C scripts.
This hole has been fixed in version 1.1c. You should
upgrade to this version with the patch provided at the WebSite
home page.
Detailed information on the actions necessary to close
the WebSite .bat file security hole can be found at this
page provided by WebSite's developer.
Q11: Are there
any known security problems with the Purveyor Server for
Windows NT?
The Purveyor Web server, all versions, is vulnerable to the
same bug that allows the source code for server-side include
files to be revealed. See the description of this bug in the
section on
Netscape Enterprise Server for
more details. Support for Purveyor was discontinued in 1997,
so no fix or upgrade is available. Your choices are to avoid
using server-side includes, or to change server software completely.
Q12: Are there
any known security problems with the Microsoft's IIS Web
Server?
Back Door Access to Protected Files, January 8, 1998
Microsoft Internet Information Server and Personal Web Server
versions 4.0 and earlier contain a bug that allows unauthorized
remote users to fetch documents that are restricted by IP
address or SSL use. This bug affects any file that does
not
use the standard DOS 8.3 naming convention. For example, if
the document is named
somelongfile.htm, then the unscrupulous
user can ask for the file SOMEF~1.HTM, which is the mangled
DOS equivalent of the file name. Even though the document
may be restricted, this fetch will succeed. Password protection,
which is accomplished through file system access control lists,
is not affected by this bug, although other file-specific
settings, such as PICS rating, are.
A patch is available on Microsoft's
security pages. Newer versions of IIS are free of the
problem.
The same bug is present in the Netscape Enterprise
and Commerce servers. Recent versions of WebSite Professional
are reportedly free of the problem
.BAT CGI Script Hole, March 1996
Versions of the Microsoft IIS server downloaded prior to 3/5/96
contain the same .BAT file bug that appears in other NT-based
servers. In fact the problem is worse than on other servers
because .BAT CGI scripts doesn't even have to be installed
on the server for a malicious remote user to invoke any arbitrary
set of DOS commands on your server!
Microsoft has released a patch for this bug, available
at http://www.microsoft.com/infoserv/.
In addition, all copies of the IIS server downloaded after
3/5/96 should be free of this bug. If you use this server,
you should check the creation date of your server binary
and upgrade it if necessary.
Versions of Microsoft IIS through 3.0 are vulnerable to
a bug that allows remote users to download and read the
contents of executable scripts, potentially learning
sensitive information about the local network configuration,
the name of databases, or the algorithm used to calculate
vendor discounts. This bug appears whenever a script-mapped
file is placed in a directory that has both execute and
read permissions. Remote users can download the script itself
simply by placing additional periods at the end of its URL.
To avoid this bug, turn off read permissions in any directory
that contains scripts. Alternatively, download the patch
provided by Microsoft at:
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postsp2/iis-fix
June 25, 1997 -- denial of service attack
IIS version 3.0 is vulnerable to a simple denial of service
attack. By sending a long URL of a particular length to an
IIS server, anyone on the Internet can cause the Web server
to crash. The server will need to be restarted manually in
order to resume Web services. A variety of Perl and Java programs
that exploit this bug are floating around the Internet, and
actual attacks have been reported.
The exact length of the URL that is required to cause the
crash varies from server to server, and depends on such
issues as memory usage. The magic length is generally around
8192 characters in length, suggesting that the problem is
a memory buffer overflow. In the past such problems have
often been exploited by knowledgeable hackers to execute
remote commands on the server, so this bug is potentially
more than annoyance.
A patch is available from Microsoft at ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postSP3/iis-fix
Q13: Are there
any known security problems with Sun Microsystem's JavaWebServer
for Windows NT?
Servlet Source Code Vulnerable to Disclosure, June 29,
1998
The JavaWebServer is able to compile and execute Java class
files in a manner similar to CGI scripts (but much more efficiently).
These small Java programs are called "servlets."
The Windows NT version of JavaWebServer
is vulnerable to a bug that allows the source code for Java
servlets to be downloaded by remote users. This bug is similar
to ones identified for Windows NT versions of O'Reilly
WebSite Professional and Netscape Enterprise
Server. By appending certain characters to the end of
a servlet's URL, a remote user can fool the server into
sending him the compiled servlet, which can then be decompiled
by a product such as Mocha. Since servlets may contain proprietary
code, trade secrets or even database access passwords, this
is a significant problem.
Sun has not yet announced a fix for this problem. Check
their Web site for details. More information can be found
at http://www.sddt.com/files/library/98/06/29/tbd.html
Q14: Are there
any known security problems with the MetaInfo MetaWeb Server?
Physical Path not Protected, June 30, 1998
MetaInfo (
www.metainfo.com)
produces a number of NT products, including a port of the
Unix Sendmail program and a DHCP/DNS server. It provides a
Web server, called MetaWeb, as a user-friendly front end to
its administration tools for these products. At the time this
was written, MetaWeb was at version 3.1.
According to Jeff Forristal, who discovered the bug, MetaWeb
is vulnerable to the "double-dot" problem that plagued early
versions of the Microsoft IIS server. By including ".."
pairs in the URL path, the server can be tricked into giving
access to directories outside the Web document root, including
documents in the Windows system directory. This allows password
files and other confidential information to be retrieved.
Worse, a variant of this attack also gives remote users
the ability to run any executable binary that happens to
be installed on the server machine.
MetaWeb has not yet made an upgrade or patch available.
You are urged to upgrade when a fix does become available.
A good short-term solution is to disable remote administration
via the Web interface.
More information about the MetaInfo bug may be posted Jeff
Forristal's site.
Unix Servers
Q15: Are there
any known security problems with NCSA httpd?
Versions of
NCSA
httpd prior to 1.4 contain a serious security hole relating
to a fixed-size string buffer. Remote users could break into
systems running this server by requesting an extremely long
URL. Although this bug has been well publicized for more than
a year, many sites are still running unsafe versions of the
server. The current version of the software, version 1.5,
does not suffer from this bug and is available at the link
given at the beginning of this paragraph.
Recently it has come to light that
example C code (cgi_src/util.c) long distributed
with the NCSA httpd as an example of how to write safe CGI
scripts ommitted the newline character from the list of
characters that are shouldn't be passed to shells. This
ommission introduces a serious bug into any CGI scripts
that were built on top of this example code: a remote user
can exploit this bug to force the CGI script to execute
any arbitrary Unix command. This is another example of the
dangers of executing shell commands
from CGI scripts.
In addition, the NCSA server source code tree itself contains
the same bug (versions 1.5a and earlier). The faulty subroutine
is identical, but in this case is found in the file src/util.c
as opposed to cgi_src/util.c. After looking through
the server source code, I haven't found a place where a
user-provided string is passed to a shell after being processed
by this subroutine, so I don't think this represents
a actual security hole. However, it's best to apply the
patch shown below to be safe.
The Apache server, versions 1.02 and earlier, also contains
this hole in both its cgi_src and src/
subdirectories. It's not unlikely that the same problem
is present in other derivatives of the NCSA source code.
The patch to fix the holes in the two util.c files
is simple. "phf" and any CGI scripts that use this library
should be recompiled after applying this patch (the GNU
patch program can be found at ftp://prep.ai.mit.edu/pub/gnu/patch-2.1.tar.gz).
You should apply this patch twice, once while inside the
cgi_src/ subdirectory, and once within the src/ directory
itself:
tulip% cd ~www/ncsa/cgi_src
tulip% patch -f < ../util.patch
tulip% cd ../src
tulip% patch -f < ../util.patch
---------------------------------- cut here ----------------------------------
*** ./util.c.old Tue Nov 14 11:38:40 1995
--- ./util.c Thu Feb 22 20:37:07 1996
***************
*** 139,145 ****
l=strlen(cmd);
for(x=0;cmd[x];x++) {
! if(ind("&;`'\"|*?~<>^()[]{}$\\",cmd[x]) != -1){
for(y=l+1;y>x;y--)
cmd[y] = cmd[y-1];
l++; /* length has been increased */
--- 139,145 ----
l=strlen(cmd);
for(x=0;cmd[x];x++) {
! if(ind("&;`'\"|*?~<>^()[]{}$\\\n",cmd[x]) != -1){
for(y=l+1;y>x;y--)
cmd[y] = cmd[y-1];
l++; /* length has been increased */
---------------------------------- cut here ----------------------------------
Q16: Are there
any known security problems with Apache httpd?
Authentication Headers, Directory Listing Bugs - 28 February
2001
Versions prior to v1.3.20 contain server programming errors
that present moderate to serious security risks. Under the
right circumstances, authentication headers would not be
provided to the client. The default configuration would
lead two modules to present directory listings instead of
presenting the default index.html file, if the URL retrieved
was artificially long and contained many slashes.
NetWare Paths - 31 January 2001
The NetWare functions created a bug whereby directives
for path settings were not interpreted correctly.
mod_rewrite Globbing - 14 Oct 2000
The mod_rewrite module, if the result of filename rewrites
caused a file to include $0 or other such references, could
result in server configuration information being presented
to a browser.
Other
Versions of Apache httpd prior to 1.2.5 contain several
programming errors that present moderate security risks.
Users who have local access to the server machine (e.g.
Web authors), can carefully craft HTML files which, when
fetched, will give the user the ability to execute Unix
commands with Web server user permissions. Since local users
usually already have as much, if not more, access to the
system as the Web server, this does not present a major
risk, but it may be of concern to ISP's who provide Web
hosting services to untrusted authors. Apache version 1.2.5
is free of these bugs; upgrade at your earliest convenience.
If you are using a 1.3 beta version of Apache, you may apply
a patch located atthe Apache site, or await the release
of 1.3b4.
Apache servers prior to 1.1.3 contain two security holes
which are of far more concern. The first hole affects servers
compiled with the "mod_cookies" module. Servers compiled
with this module contain a vulnerability that allows remote
users to send the server extremely long cookies and overrun
the program stack, potentially allowing arbitrary commands
to be executed. Because this gives remote users access to
the server host, it is a far greater vulnerability than
the holes discussed above, which only can be exploited by
local users.
The second problem with 1.1.1 affects automatic directory
listings. Ordinarily, a remote user cannot obtain a directory
listing if the directory contains a "welcome page", such
as "index.html". A bug causes this check to fail under certain
circumstances, allowing the remote user to see the contents
of the directory even if the welcome page is present. This
hole is less serious than the first one, but is still a
potential information leak.
More information and current Apache binaries can be found
at:
http://www.apache.org/
Q17: Are there
any known security problems with the Netscape Servers?
Netscape Enterprise server versions 3.6sp2 and earlier, as
well as FastTrack server versions 3.01 and earlier contain
a buffer overflow bug that can allow a remote user to gain
shell access to the server machine. More information on this
problem, as well as pointers to patches, can be found at
http://www.ciac.org/ciac/bulletins/j-062.shtml.
There have also been two well-publicized recent episodes
in which the system used by the Netscape
Secure Commerce Server to encrypt sensitive communications
was cracked. In the first episode, a single message encrypted
with Netscape's less secure 40-bit encryption key was cracked
by brute force using a network of workstations. The 128-bit
key used for communications within the U.S. and Canada is
considered immune from this type of attack.
In the second episode, it was found that the random number
generator used within the server to generate encryption
keys was relatively predictable, allowing a cracking program
to quickly guess at the correct key. This hole has been
closed in the recent releases of the software, and you should
upgrade to the current version if you rely on encryption
for secure communications. Both the server and the
browser need to be upgraded in order to completely close
this hole. See http://home.netscape.com/newsref/std/random_seed_security.html
for details.
Q18: Are there
any known security problems with the Lotus Domino Go Server?
Bill Jones
<sneex@mac.com>
reports that older versions of Lotus Domino Go, formerly known
as IBM Internet Connection Server (ICS), contained a security
hole in directory browsing. When directory browsing is set
to "fancy", a potential hacker can browse backward through
the directory tree all the way up to root ("/"). Thus, private
system files and other documents are exposed to interception.
This bug was present in versions 1.0 through 2.0 of ICS, and
affected both the AIX and OS/2 Warp versions.
According to Richard L. Gray (rlgray@us.ibm.com>)
of IBM, all known problems have been fixed in versions 4.2.1.3
and higher. Lotus Domino Go also now runs on Windows 95,
Windows NT, OS/390, HPUX and Solaris systems.
Q19: Are there
any known security problems with the WN Server?
The
WN server is free
of any known security holes. As explained in
Q6
it contains several features that lessen the chance that security
will be breached by improper server configuration.
Macintosh Servers
Q20: Are there
any known security problems with WebStar?
There is a gaping hole in WebSTAR's handling of log files.
If you install WebSTAR using the default configuration, the
server's log file will be located within the document tree.
Anyone on the Internet can download the entire server log
and review all remote accesses to the server simply by requesting
the URL "http://your.site/WebSTAR%20LOG ". As discussed
in
Server Logs and Privacy, this
is a violation of users' expectation to privacy. Use WebSTAR's
administrative tool to change the location of the log file
to some place outside the document tree.
As far as the security of the WebSTAR server itself goes,
there is reason to think that WebSTAR is more secure than
its Unix and Windows counterparts. Because the Macintosh
does not have a command shell, and because it does not allow
remote logins, it is reasonable to expect that the Mac is
inherently more secure than the other platforms. In fact
this expectation has been borne out so far: no specific
security problems are known in either WebStar or its shareware
ancestor MacHTTP.
In early 1996 a consortium of Macintosh Internet software
development companies, including StarNine, the developer
of WebStar, posted a $10,000 reward to anyone who could
read a password-protected Web page on a Macintosh running
WebStar software. As described in an article about the challenge
in Tidbits#317/04-Mar-96,
after 45 days no one had stepped forward to claim the prize.
Although one cannot easily "break in" to a Macintosh host
in the conventional way, potential security holes do exist:
- Exploiting holes in the server to read files outside
the official document tree.
- Finding a way to crash the server.
- Exploiting holes in CGI scripts to execute AppleScript
commands. This particularly of concern for Perl scripts.
All the caveats and warnings about safe
scripting apply.
In fact, a repeat "Crack-a-Mac" challenge in 1997, sponsored
by a Swedish consulting company, was not so fortunate. In
this case, a cracker was able to break into the server and
steal the protected page by exploiting bugs in two server
remote administration and editing add-ons. This emphasizes
the risk that you runs whenever you add CGI scripts, server
modules, and other extensions to Web servers. Details on the
successful break-in, along with links to patched server extensions,
can be found at
http://hacke.infinit.se/
Q21: Are there
any known security problems with MacHTTP?
MacHTTP shares WebSTAR's problem with log files. See the discussion
above.
Q22: Are there
any known security problems with Quid Pro Quo?
The Quid Pro Quo server saves its default log file inside
the document root, at URL
http://site.name/server%20logfile.
A knowledgeable remote user can find out every access that
anyone's made to your server!
(This information provided by Paul DuBois <dubois@primate.wisc.edu>).
Other Servers
Q23: Are there
any known security problems with Novell WebServer?
If you are running Novell Webserver version 3.x and have the
Web Server Examples Toolkit v.2 installed, you have a major
security hole. Users can view any file on your system and
download directory listings, possibly gaining information
needed to break into your system. The hole is in the example
CGI Perl script files.pl. Remove it from your /perl directory
(typically located in SYS:INW_WEB\SHARED\DOCS\LCGI\PERL5.
Better yet, remove
all CGI scripts that are not essential
for the operation of your site.
(Thanks to
Bob Bagwill
who contributed many of the Q&A's in this section)
Most servers log every access. The log usually includes
the IP address and/or host name, the time of the download,
the user's name (if known by user authentication or obtained
by the identd protocol), the URL requested (including the
values of any variables from a form submitted using the
GET method), the status of the request, and the size of
the data transmitted. Some browsers also provide the client
the reader is using, the URL that the client came from,
and the user's e-mail address. Servers can log this information
as well, or make it available to CGI scripts. Most WWW clients
are probably run from single-user machines, thus a download
can be attributed to an individual. Revealing any of those
datums could be potentially damaging to a reader.
For example, XYZ.com downloading financial reports on ABC.com
could signal a corporate takeover. The accesses to a internal
job posting reveals who might be interested in changing
jobs. The time a cartoon was downloaded reveals that the
reader is misusing company resources. A referral log entry
might contain something like:
file://prez.xyz.com/hotlists/stocks2sellshort.html -> http://www.xyz.com/
The pattern of accesses made by an individual can reveal
how they intend to use the information. And the input to
searches can be particularly revealing.
Another way Web usage can be revealed locally is via browser
history, hotlists, and cache. If someone has access to the
reader's machine, they can check the contents of those databases.
An obvious example is shared machines in an open lab or
public library.
Proxy servers used for access to Web services outside an
organization's firewall are in a particularly sensitive
position. A proxy server will log every access to the outside
Web made by every member of the organization and track both
the IP number of the host making the request and the requested
URL. A carelessly managed proxy server can therefore represent
a significant invasion of privacy.
Yes. One of the requirements of responsible net citizenship
is respecting the privacy of others. Just as you don't forward
or post private email without the author's consent, in general
you shouldn't use or post Web usage statistics that can be
attributed to an individual.
If you are a government site, you may be required by law
to protect the privacy of your readers. For example, U.S.
Federal agencies are not allowed to collect or publish many
types of data about their clients.
In most U.S. states, it is illegal for libraries and video
stores to sell or otherwise distribute records of the materials
that patrons have checked out. While the courts have yet
to apply the same legal standard to be applied to electronic
information services, it is not unreasonable for users to
have the same expectation of privacy on the Web. In other
countries, for example Germany, the law explicitly forbids
the disclosure of online access lists. If your site chooses
to use the Web logs to populate your mailing lists or to
resell to other businesses, make sure you clearly advertise
that fact.
One of the requirements of your Web site may be to collect
statistics on usage to provide data to the organization and
to justify Web site resources. In general, collecting information
about accesses by individuals is probably not warranted or
even useful.
The easiest way to avoid collecting too much information
is to use a server that allows you to tailor the output
logs, so that you can throw away everything but the essentials.
Another way is to regularly summarize and discard the raw
logs. Since the logs of popular sites tend to grow quickly,
you probably will need to do that anyway.
There are two classes of readers: outsiders reading your documents,
and insiders reading your documents and outside documents.
You can protect outsiders by summarizing your logs. You
can help protect insiders by:
- having a clear site policy on Web usage.
- educating them about the site policy and risks of Web
usage.
- using a site-wide proxy cache to hide the identity of
individual hosts from outside servers.
If your site does not want to reveal certain Web accesses
from your site's domain, you may need to get Web client
accounts from another Internet provider that can provide
anonymous access.
