![[W3C]](i/w3c_home.gif){kind=small}
The World Wide Web Security FAQ
The World Wide Web Security FAQ
 Up to Table of Contents | ||
 Back to Client Side Security | Forward to Bibliography |
Netscape has announced that a patch will be made available. As of January 16, 1998, it has not yet been posted to their Web site.
The same bug is present in the Microsoft IIS server. Recent versions of WebSite Professional are reportedly free of the problem
/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.
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.
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.
The EMWACS NT server, from which Purveyor is derived, also appears to be safe from this problem.
Microsoft has announced that a patch will be made available. As of January 16, 1998, the patch has not yet been posted to their Web site. Microsoft's security bulletin strongly advises Webmasters to place servers that contain sensitive information behind a firewall, a tacit warning that there are likely to be more security-related bugs in the product.
The same bug is present in the Netscape Enterprise and Commerce servers. Recent versions of WebSite Professional are reportedly free of the problem
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
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
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 ----------------------------------
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/
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.
The Web server that came with the very first version of OS/2-Warp has a related issue. Overly-promiscuous factory defaults allow remote users to browse beyond the root directory and onto network-mounted disk shares.
I have no information on whether these holes have been patched in more recent versions of ICSS. Please let me know if you have further information.
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:
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/
(This information provided by Paul DuBois <dubois@primate.wisc.edu>).
|
Up to Table of Contents | ||
|
Back to Client Side Security | Forward to Bibliography |
Lincoln D. Stein (lstein@w3.org)
Last modified: Fri Jan 16 10:39:46 EST 1998