[W3C] The World Wide Web Security FAQ


DISCLAIMER

This information is provided by Lincoln Stein (lstein@cshl.org). The World Wide Web Consortium (W3C) hosts this document as a service to the Web Community; however, it does not endorse its contents. For further information, please contact Lincoln Stein directly.

^ Up to Table of Contents
<< Back to Client Side Security
Forward to Bibliography >>


10. Problems with Specific Servers

Windows NT Servers

Q73: 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 Redfernredferni@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.

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

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

Q76: 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

Q77: 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

Q78: 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

Q79: 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 ----------------------------------

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

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/

Q81: 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 http://home.netscape.com/newsref/std/random_seed_security.html for details.

Q82: Are there any known security problems with the Lotus Domino Go Server?

Bill Jones <webmaster@fccj.cc.fl.us> 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.

Q83: 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

Q84: 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:

  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.

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/

Q85: Are there any known security problems with MacHTTP?

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

Q86: 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

Q87: 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.
^ Up to Table of Contents
<< Back to Client Side Security
Forward to Bibliography >>

Lincoln D. Stein (lstein@cshl.org)

Last modified: Mon Sep 13 13:53:46 EDT 1999 ?