The World Wide Web Security FAQ

10. Problems with Specific Servers

Windows NT Servers

Q65: Are there any known security problems with the Netscape Communications Server for NT?

The NT versions of the Netscape servers (both the Netscape Communications Server version 1.12 and the Netscape Commerce Server) have two problems involving the handling of CGI scripts. One of these problems is also shared by the WebSite Server

Perl CGI Scripts are Insecure

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?&

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

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

An Untested Workaround for the .bat File Hole

It's possible to use .bat files safely by wrapping them in a compiled .exe file. The .exe file first checks the command line parameters extremely carefully for things that might be misinterpreted by DOS, then invokes a subshell, and executes the .bat.

This requires some care, and it might be easier to do everything in compiled code. Brian Kendig reports that Netscape is aware of the problem and is working on a wrapper script with the functionality described above.

Q66: Are there any known security problems with the O'Reilly WebSite server for Windows NT/95

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.

Q67: Are there any known security problems with the Purveyor Server for Windows NT?

According to the developers of Purveyor, they anticipated the .bat file security hole during the software's development. It's immune to this problem.

The EMWACS NT server, from which Purveyor is derived, also appears to be safe from this problem.

Q68: Are there any known security problems with the Microsoft's IIS Web Server

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

Unix Servers

Q69: 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 trees 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 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 ****
      for(x=0;cmd[x];x++) {
!         if(ind("&;`'\"|*?~<>^()[]{}$\\",cmd[x]) != -1){
                  cmd[y] = cmd[y-1];
              l++; /* length has been increased */
--- 139,145 ----
      for(x=0;cmd[x];x++) {
!         if(ind("&;`'\"|*?~<>^()[]{}$\\\n",cmd[x]) != -1){
                  cmd[y] = cmd[y-1];
              l++; /* length has been increased */
---------------------------------- cut here ----------------------------------

Q70: Are there any known security problems with CERN httpd?

No security problems have been reported with the CERN server to date.

Q71: Are there any known security problems with Apache httpd?

No problems have been reported with Apache httpd to date. However see the discussion of bugs in the util.c CGI example code distributed with Apache and NCSA httpd for important warnings about CGI scripts built on top of this code.

Q72: Are there any known security problems with the Netscape Servers?

The Netscape Communications Server does not contain any known security holes.

There have, however 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 for details.

Q73: Are there any known security problems with the IBM Internet Connection Secure Server for AIX?

According to IBM's representative Mike Kearney ( the IBM Internet Connection Secure Server is free of any known security holes. The server supports both SSL and SHTTP protocols, and is also available for OS/2 and OS/2-Warp.

Q74: Are there any known security problems with the WN Server?

The WN server is free of any known security holes. As explained in Q7 it contains several features that lessen the chance that security will be breached by improper server configuration.

Macintosh Servers

Q75: 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 " ". 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.

Recently 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 "break in" to a Macintosh host in the conventional way, potential security holes do exist:

  1. Exploiting holes in the server to read files outside the official document tree.
  2. Finding a way to crash the server.
  3. 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.

Q76: Are there any known security problems with MacHTTP?

MacHTTP shares WebSTAR's problem with log files. See the discussion above.

Lincoln D. Stein,
Whitehead Institute/MIT Center for Genome Research
Last modified: Fri Nov 8 10:20:07 EST 1996