SecurityTracker.com
Keep Track of the Latest Vulnerabilities
with SecurityTracker!
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 
Sign Up
Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Instant Alerts
Buy our Premium Vulnerability Notification Service to receive customized, instant alerts
Affiliates
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Partners
Become a Partner and License Our Database or Notification Service
Report a Bug
Report a vulnerability that you have found to SecurityTracker
bugs
@
securitytracker.com






Category:   Application (Web Server/CGI)  >   WASD VMS Hypertext Services Vendors:   Daniel, Mark G.
WASD HTTP Server for OpenVMS Has Multiple Flaws That Disclose Information and Let Remote Users Gain SYSTEM Access
SecurityTracker Alert ID:  1005301
SecurityTracker URL:  http://securitytracker.com/id/1005301
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Sep 26 2002
Impact:   Denial of service via network, Disclosure of system information, Disclosure of user information, Modification of system information, Modification of user information, Root access via network
Fix Available:  Yes  Vendor Confirmed:  Yes  
Version(s): WASD 7.1, 7.2 (up to 7.2.3), 8.0, and possibly earlier versions.
Description:   Several vulnerabilities were reported in the WASD HTTP Server for the OpenVMS operating system. A remote user can write to arbitrary files with SYSTEM privileges, view various files on the system, and obtain information about the system.

The server's default configuration reportedly allows remote users to view and traverse the entire directory tree of the web server using the following type of URL:

http://webserver/tree/
http://webserver/dirname/*.*
http://webserver/upd/dirname/

A remote user can search all documents on the web server (a default setting).

A remote user can gain read access to critical files in the main server root directory (which is, by default, the same as the root document directory).

A remote user can reportedly bypass access restrictions using the following type of URL:

http://theserver/ht_root/wwwroot/-/*.*

(Note: "-" is the VMS equivalent of "..").

A remote user can determine the location of the document root using the built-in "where" script. If the "where" script is not enabled, the HTTP 404 "Page Not Found" error message will disclose the document root location.

A remote user can bypass access restrictions and obtain the web server configuration file using the following type of URL:

http://theserver/ht_root/wwwroot/-/local/httpd$map.conf

A remote user can obtain the web server logs with the following type of URL (if the logs are not sufficiently protected):

http://theserver/upd/ht_root/src/-/log/

A remote user can view hidden directories using the "tree" script:

http://theserver/tree/ht_root/

A remote user can view a list of CGI scripts on the server:

http://theserver/ht_root/wwwroot/-/script_local/*.*

A remote user can view the source code of CGI scripts, either directly or using the default "extract" script:

http://theserver/ht_root/wwwroot/-/script_local/scriptname
http://theserver/extract/~username/cgi-bin/scriptname.com?highlight=$

A remote user can view some system files and user files. An example exploit URL is provided:

http://theserver/sys$common/syslib/-/sysmgr/systartup_vms.com
http://theserver/~username/-/*.*
http://theserver/~username/x/--/*.*

The default configuration runs CGI scripts with the privileges of the main server. The server reportedly runs the image httpd.exe (or httpd_ssl.exe) under the identity of user http$server. CGI scripts are run with the same identity. As a result, a CGI error can affect the entire web server.

One default CGI script allows a remote user to write arbitrary contents to arbitrary files on the system (provided that the OpenVMS ACLs allow the file to be created). A remote user can exploit this to gain SYSTEM privileges on the server.

Another default CGI script (cgi_process.com) reportedly discloses sensitive information to remote users. A demonstration exploit URL is provided:

http://theserver/cgi-bin/cgi_process

A format string flaw was reported in the PerlRTE_example1.pl script and a potential denial of service vulnerability was reported in the print.com script.

Impact:   A remote user can write arbitrary contents to arbitrary files with SYSTEM level privileges. A remote user can view files on the server and obtain information about the server.
Solution:   The vendor has released fixed versions (7.2.4 or later, 8.0.1 or later), available at:

http://wasd.vsm.com.au/wasd/

An INSTALL_SECURE kit is also available. Sites with versions earlier than 7.2 are encouraged to update to at least 7.2, although the INSTALL_SECURE procedure can be applied alone with significant improvements to site security (but without the server image fixes).

The vendor has provided the following instructions:

o Be prepared to spend some time revalidating your site, especially local scripts and tools, AND for some disruption.

o Shut down the server and any associated detached applications such as the HyperSPI agent.

o Apply the update kit and rebuild or relink the package as appropriate.

o @INSTALL_SECURE.COM Read the information pages carefully. They explain what is involved and about to be done. Once started do not interrupt the procedure's activities (if you do just restart it again, it can be applied multiple times).

o @HT_ROOT:[STARTUP]STARTUP Restart the server (note the new startup procedure location).

o Evaluate the migration by checking document availability and script functionality. Expect that some parts of the tree that were formerly accessible to be restricted and some example scripts that were active also now be restricted.

o Modify site startup procedures, etc., to reflect the new directory structure and startup file locations.

o Email the info-WASD mailing list or the author with specific queries. info-WASD@vsm.com.au (if a subscriber) Mark.Daniel@wasd.vsm.com.au (all and sundry)

See the Vendor URL for further instructions.

Vendor URL:  wasd.vsm.com.au/ht_root/doc/misc/wasd_advisory_020925.txt (Links to External Site)
Cause:   Access control error, Configuration error, Input validation error
Underlying OS:  OpenVMS

Message History:   None.


 Source Message Contents

Subject:  remote SYSTEM compromise in WASD OpenVMS http server


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

    
        Multiple vulnerabilities in WASD http server for OpenVMS


Version 1.0, 25 Sept 2002.

0. Contents

  1. Summary
  2. Severity: Critical
  3. Vulnerable versions
  4. Description
  5. Solutions
  6. Examples of site weaknesses
  7. Conclusion
  8. Acknowledgments
  9. Document history


1. Summary

  WASD VMS Hypertext Services is a popular http server for OpenVMS
  released under the GNU GPL. See http://wasd.vsm.com.au/WASD/
  The default installation of the WASD server allows:

  - universal directory traversal
  - instant access to the entire web server tree
  - trivial bypassing of access control rules
  - getting the location of the document root
  - read access to the whole web server configuration
  - read access to all web server logs
  - disclosure of directories supposed to be hidden
  - getting the list of all cgi scripts
  - getting the sources of all cgi scripts
  - read access to OpenVMS system files
  - user home directories might be readable
  - one very serious flaw in a cgi script enabled by default
  - some problems with other cgi-scripts enabled by default


2. Severity: Critical

  When combining different vulnerabilities, a remote SYSTEM (root)
  compromise is possible in a default installation of WASD versions
  up to 8.0.

  Even without compromising the system, important files which are
  supposed to stay confidential can easily be read remotely.


3. Vulnerable versions

  WASD 7.1, 7.2 (up to 7.2.3), 8.0, and possibly earlier versions.

  WASD 8.1, and the update versions 8.0.1 and 7.2.4, will fix the
  known vulnerabilities.


4. Description

  The main problems are:
  - the default configuration is much too liberal
  - the access control rules can be trivially bypassed
  - cgi scripts are run by default under the identity of the main server

  There are also problems with some cgi scripts provided by default,
  at least one of which is very serious.

  4.1 The default configuration is much too liberal

  4.1.1 The builtin "tree" script

     By default the entire directory tree of the web server can be
     seen with http://webserver/tree/
     Documentation: http://wasd.vsm.com.au/ht_root/doc/env/env_0400.html#43
     Example: http://wasd.vsm.com.au/tree/

   4.1.2 "/*.*" directory traversal

     Universal directory traversal is builtin with
     http://webserver/dirname/*.* even if there is a page /dirname/index.html
     Documentation: http://wasd.vsm.com.au/ht_root/doc/env/env_0400.html

   4.1.3 The builtin "upd" script

     A nice graphical interface for directory traversal is builtin with
     http://webserver/upd/dirname/ even if there is a page /dirname/index.html
     Documentation: http://wasd.vsm.com.au/httpd/-/updhelp.html

   4.1.4 The builtin search 

     All documents can be searched by default.
     Documentation: http://wasd.vsm.com.au/ht_root/doc/env/env_0700.html#97

   4.1.5 Most of the server root is accessible by default

     The document root is the main server root, which includes everything
     (configuration files, scripts, executables, etc...). Directory traversal
     is enabled on most of the directories and access to the other
     directories is possible anyway (see later).

   The WASD documentation states that the liberal option was on purpose:
   http://wasd.vsm.com.au/ht_root/doc/htd/htd_0600.html#98

     "The default configuration is fairly liberal, providing information
      of use in a technical environment, but that may be superfluous or
      less-than-desirable in other, possibly commercial environments."

   OpenVMS has a reputation of being a very secure operating system.  This may
   explain why VMS system administrators may have a false sense of security
   when installing the WASD web server and leave the default configuration
   almost untouched.

   The default configuration in WASD 8.1 will be much more restrictive.


   4.2 The access control rules can be trivially bypassed

   All the liberal features described above can be used to bypass
   the few restrictions set by the web server.

   4.2.1 Bypassing access restrictions set by the web server

     The configuration file httpd$map.conf contains rules such as:

	pass /ht_root/wwwroot*
	fail /ht_root/*
	fail /-/*

      In this example, the server root is ht_root and the document root is
      wwwroot. The "fail" rules attempt to restrict access to the server
      root but can be trivially bypassed with:

        http://theserver/ht_root/wwwroot/-/*.*

     (note: "-" is the VMS equivalent of ".."). So the only real protection
     comes from the directory protections and ACLs (access control lists)
     imposed by the operating system. (See section "Solutions" below.)

   4.2.2 The location of the document root can easily be obtained

     The location of the document root can easily be obtained with the "where"
     builtin script.
     Documentation: http://wasd.vsm.com.au/ht_root/doc/htd/htd_2100.html#364

     Even if the "where" script is not enabled, the "404 not found" message
     gives away the document root.  On a server where the document root was
     (correctly) not the entire web server root (logical name HT_ROOT), the
     real document root could still be obtained with
     http://theserver/notfound which gives "Document not found ...
     /ht_root/wwwroot/notfound" This allows getting the entire web server
     root with http://theserver/ht_root/wwwroot/-/*.* as described above.

     The full physical path may also be given hidden as a comment in the html
     returned in the "404 not found" message:
         <!-- sts: %X00018292 "$1$DUA2:[HT_ROOT.][WWWROOT]NOTFOUND" -->

   4.2.3 The full web server configuration can easily be obtained

     The web server configuration file in ht_root/local/httpd$map.conf
     is generally supposed to be protected by a fail rule:

        fail /ht_root/local/*
     
     However this can often be trivially bypassed as shown above:

        http://theserver/ht_root/wwwroot/-/local/httpd$map.conf

      On one of the machines tested, there was even no "fail" rule so the
      configuration could be obtained directly as
        http://theserver/local/httpd$map.conf

      The configuration file httpd$map.conf gives a lot of information to
      intruders, in particular all the access control rules, all the script
      directories, all the virtual domains handled, all the accessible
      directories not under ht_root, etc...

   4.2.4 All the web server logs can easily be obtained

      This is just a variation on the above. There is generally a rule

         fail /ht_root/log/*

      but all the logs can generally be obtained with
      http://theserver/upd/ht_root/src/-/log/
      unless they are protected with adequate ACLs.

      If the logs are protected by ACLs but you have a user account on
      the machine hosting the web server, then some of the logs may still
      be obtained because the last request may be available in the
      logical name (environment variable) HTTPD80$REQUEST :

      $ show log HTTPD80$REQUEST
      "HTTPD80$REQUEST" = "08 11:56:42.200.430.5287.0.9000.http://theserver:
       80.ip.address.of.caller.GET /filename"

      The logical name is dynamically updated at each request. However this
      was observed on only one system with an old version of WASD so the
      problem may be fixed in 8.0.

    4.2.5 The "tree" builtin script shows directories supposed to be hidden

      The server logs are actually in a subdirectory /ht_root/log/server/
      Since there is generally a fail rule for /ht_root/log/*
      the subdirectory server is supposed to be hidden, but the "tree"
      builtin script happily shows it:
          http://theserver/tree/ht_root/

    4.2.6 Directory protection can be bypassed anyway

      Some directories are better protected and are not even visible with
      the "tree" builtin scripts. On one tested site, the directory
      /ht_root/script_local/ exists but cannot be seen with
      /ht_root/script_local/*.* or with /tree/. This site has probably used
      the following configuration described in
      http://wasd.vsm.com.au/ht_root/doc/htd/htd_0600.html#99

        [DirAccess] - Make "disabled" to completely remove the ability
        to generate directory listings under any circumstances.

      However the search feature comes to rescue, and the directory
      (together will all its scripts, see next section) can still be seen
      with http://theserver/.../*.com?search=$

      If even the standard search feature has been disabled, one can also
      try the default glist script, which is supposed to give only a list
      of images but also gives all subdirectories:
         http://theserver/cgi-bin/glist/ht_root/?list=now

      In any case, on this particular server the directory script_local
      is given in /robots.txt so it is not difficult to see that it exists.

    4.2.7 The list of cgi scripts can easily be obtained

      It is not possible to see the list of cgi scripts with the url
      http://theserver/cgi-bin/*.* however the scripts are generally in
      ht_root/script/ or ht_root/script_local.  If a configuration rule is
      supposed to block access to these directories (either because the
      document root is correctly separated from the server root, or because
      there is an explicit rule blocking script/*), it is generally possible
      to get the list of scripts and their sources with an url such as:

        http://theserver/ht_root/wwwroot/-/script_local/*.*

      For cgi scripts of users, which can be run with url
        http://theserver/~username/cgi-bin/scriptname
      it is a bit less trivial to obtain the list of scripts because
      the obvious attempts fail:
        http://theserver/~username/cgi-bin/*.*

      but the following generally works:
        http://theserver/~username/xxx/-/cgi-bin/*.*
      where xxx doesn't have to be an existing directory.

      If it doesn't work, then the search feature can generally be used:
        http://theserver/~username/.../*.com?search=$

      (note: on OpenVMS "..." indicates directory recursion).  This searches
      all the *.com scripts for the character $ which always starts a command
      on OpenVMS, and so gives as a result the full list of all .com scripts
      under all subdirectories of the home directory. It is even possible to
      search *.* instead of *.com.

    4.2.8 The sources of cgi scripts can easily be obtained

      After the list of scripts has been obtained as above, it is trivial
      to get the sources of the scripts by clicking on a link. For general
      server scripts the link can be of the form:
        http://theserver/ht_root/wwwroot/-/script_local/scriptname

      For user scripts obtained by the search feature, the link is:
        http://theserver/extract/~username/cgi-bin/scriptname.com?highlight=$

      Here "extract" is a script provided by default by WASD. It allows
      getting the source of a script instead of executing it, even if the
      directory containing the script is named cgi-bin.

    4.2.9 OpenVMS system files can generally be read

       On several tested sites, a configuration rule is supposed to
       give access to only a selected portion of system files:

         pass /sys$common/syslib/* /sys$common/syslib/*

       However other system files can easily be read, for example
       http://theserver/sys$common/syslib/-/sysmgr/systartup_vms.com

     4.2.10 User home directories might be readable

       It is common practice to map url http://theserver/~username/ to 
       a subdirectory /user_disk/username/web/ of the home directory
       /user_disk/username/. But if the OpenVMS protections and ACLs on
       the home directory are not set correctly, it is possible to traverse
       it with: 
         http://theserver/~username/-/*.*

       Actually this often returns an error because of a strange mapping rule:
         pass /*/-/* /ht_root/runtime/*/*

       but it is easy to work around this rule with:
         http://theserver/~username/x/--/*.*

       where x doesn't have to be the name of an existing directory,
       and "--" represents for VMS the equivalent of "../.."

       In one of the sites tested, there was even no mapping to a subdirectory
       so the whole user home directory was available with
         http://theserver/~username/*.*


   4.3  CGI scripts are run by default under the identity of the main server

     By default the server runs the image httpd.exe (or httpd_ssl.exe)
     under the identity of user http$server. CGI scripts are also run by
     default under the same identity. Thus a flaw in one CGI script can affect
     the entire server.

     On Unix, the main server is typically run as root but CGI scripts are
     typically run under user "nobody". Thus a bad script cannot affect the
     entire server.

     The WASD server allows running CGI scripts as a user other than
     http$server. This will be the default in WASD 8.1.


   4.4 Problems with some cgi scripts enabled by default

     I have not studied all scripts provided in a default installation
     of WASD. But at least one is very dangerous and there are some bugs
     in others.

     4.4.1 Write to an arbitrary file on the web server

       One script enabled by default allows writing contents of the attacker's
       choice to an arbitrary file on the server, as long as the VMS ACLs
       allows it. This flaw can be exploited to get a remote SYSTEM (root)
       compromise.

       Given the severity of this flaw, no details are given here. See the
       "Solutions" section below for temporary workarounds.

     4.4.2 Severe leakage of information in cgi_process.com

       Running http://theserver/cgi-bin/cgi_process gives a *lot* of useful
       information for an intruder. In particular it gives all the privileges
       owned by the script while running. (For Unix users: a script run with
       privileges is somewhat equivalent to a setuid or setgid program, but
       with much finer control on the actions allowed for the program.)

       On one system, the script could be run with the SETPRV privilege, which
       is equivalent to setuid root on Unix. This tells an intruder that
       efforts should be concentrated on this particularly vulnerable server.

     4.4.3 Format string bug in PerlRTE_example1.pl

       See http://wasd.vsm.com.au/ht_root/src/perl/readmore.html
       for a description of this script and its sources. It contains
       in particular:
	   printf ("$name=\"$ENV{$name}\"\n");

       The variable $name comes from the user and is not filtered, so a
       classic format string attack is possible. For example:
	 http://wasd.vsm.com.au/plrte/PerlRTE_example1/%25x%25x%25x

       (where %25 is the hex encoding of the character '%') gives:

	  PATH_INFO="/000"
	  PATH_TRANSLATED="HT_ROOT:[000000]000"
	  REQUEST_URI="/plrte/PerlRTE_example1/   0   0   0"

       where the number of zeroes is the number of %x format indicators.
       This bug is probably not exploitable, but this should be checked.

       This script also gives away a lot of potentially useful information
       for an intruder (all logical names).

     4.4.4 Potential denial of service in print.com

       The cgi script print.com allows printing a file on the server
       from a remote location. This script is enabled by default. The source
       is available at http://wasd.vsm.com.au/script/print.com
       This script attempts to restrict the IP addresses allowed to print:

         $ HPRINTS_ALLOWED = "131.185.250.*"

       Anyone in this IP range can force the printer to run out of paper.
       Anyway, it should be fairly easy to spoof the source IP address.


5. Solutions

  The WASD documentation has a section "Securing the site":

     http://wasd.vsm.com.au/ht_root/doc/htd/htd_0600.html#98

  This is essential reading for any administrator of a WASD server.
  However some of the recommendations are not effective. In particular
  the example given in section "Package tree" to block all access to the
  /ht_root/ tree except for selected areas, does not work correctly
  for WASD versions up to 8.0.

  Here is a list of minimum recommendations, which can be put in place
  even with the existing versions WASD (up to 8.0). Such recommendations
  might seem obvious for Apache users, but unfortunately many of the WASD
  sites which were tested didn't follow these basic recommendations.

  5.1 Check for new WASD versions at http://wasd.vsm.com.au/WASD/

    At the time of writing this advisory, version 8.1 of WASD is in
    preparation. It will fix all the known security problems, provide
    from installation a directory structure and associated permissions
    facilitating minimum necessary upward security adjustments, and use
    much more restrictive default access rules than previous versions.

    An advisory written by the WASD author should be available at
    http://wasd.vsm.com.au/ht_root/doc/misc/wasd_advisory_020925.txt

    Existing versions 8.0 and 7.2 will each have an update kit
    available (8.0.1 and 7.2.4 or later).  These will include a server
    with fixes for all known security issues and a script
    install_secure.com which adjusts the existing directory structure
    and permissions to conform with that implemented for 8.1.

    If these updates and/or version 8.1 or later is not available or
    not applicable to a given site, then check for a kit that provides
    just the install_secure.com script.  This can be used standalone on
    7.x and 8.0 installations for significant improvements to site
    security.

    If none of these are available or applicable to a given site, then
    take at least the minimum precautions described below in sections
    5.2 to 5.6.

  5.2 Use a separate document root, not the whole web server root

    Put the document root in /ht_root/wwwroot, not /ht_root, with mapping
    rules such as:
       pass /* /ht_root/wwwroot/*
       fail /ht_root/*

    You can add a rule such as
       fail /-/*
    but unfortunately it will not be very effective because it can be
    trivially bypassed with all versions of the WASD server up to 8.0.

  5.3 Use a subdirectory for a user document root, not the home directory

    Use rules such as:
      user /~*/*    /user_disk/*/web/*
      redirect /~*  /~*/

  5.4 Set file protections and ACLs correctly

    Since the WASD access restrictions can be bypassed, the only effective
    protection is that provided by the system itself, OpenVMS. The web server
    runs by default as user http$server, so make sure that directories
    supposed to be protected are not readable by this user. Take at least
    the following minimum precautions:

    . Make sure that all directories under ht_root are owned by user
      SYSTEM, not by user HTTP$SERVER. Add specific ACLs for directories
      and files which must be readable or writable by HTTP$SERVER, but only
      these:

       $ set file /owner=system /prot=(s:rwed,o:rwed,g,w) -
           ht_root:[000000]local.dir, ht_root:[local...]*.*;* , -
           ht_root:[000000]http$server.dir, ht_root:[http$server...]*.*;*

       $ set security /acl=((ident=http$server,access=e) /delete=all -
           ht_root:[000000]local.dir
       $ set security /acl=((ident=http$server,access=r+e) /delete=all -
           ht_root:[local]*.com;*
       $ set security /acl=((ident=http$server,access=r+e) /delete=all -
           ht_root:[http$server]*.com;*

      Be particularly careful about ACLs on files in directory [local].
      Only the .com files there should be readable by http$server; the
      rest contains very sensitive information.

    . To prevent all the different ways of reading scripts, set protection
      Execute only instead of Read+Execute on all essential scripts
      (and delete all other scripts as described below). Check at least
      the directories /script, /script_local, /vax and /axp, plus any other
      directories mentioned in the logical name CGI-BIN.

       $ set file /owner=system /prot=(s:rwed,o:rwed,g,w) -
           ht_root:[000000]script*.dir, ht_root:[script*...]*.*;* , -
           ht_root:[000000]axp.dir, ht_root:[axp...]*.*;* , -
           ht_root:[000000]vax.dir, ht_root:[vax...]*.*;*

       $ set security /acl=((ident=http$server,access=e) /delete=all -
           ht_root:[000000]script*.dir
       $ set security /acl=((ident=http$server,access=e) /delete=all -
           ht_root:[script*]*.*;*
       $ set security /acl=((ident=http$server,access=e) /delete=all -
           ht_root:[000000]axp.dir ! or vax.dir depending on architecture
       $ set security /acl=((ident=http$server,access=e) /delete=all -
           ht_root:[axp]*.*;* ! or [vax]*.*;* depending on architecture

    . To prevent reading the web server logs, set ACLs to allow write-only
      access for user http$server on directory [log] and its subdirectories.

    . To prevent all the forms of directory traversal, set protection
      Execute only instead of Read+Execute for directories which must
      be protected from traversal. You can also add rules in httpd$map.conf

	fail /tree/
	fail /tree/*
	fail /upd/*
	fail /where/*
	fail /query/*
	fail /extract/*

      but do not rely only on these rules, set ACLs correctly first.

  5.5 Remove all unused cgi programs

    This is a basic principle, but unfortunately it was not followed in
    any of the tested sites: remove *all* unused cgi scripts and executables.
    Some of the programs provided by default with the WASD server are
    very dangerous. So check at least the directories script, script_local,
    axp and vax (all under ht_root) and move anything which is unused
    somewhere outside ht_root, with very strict ACLs.

    Let me insist again: at least one of the programs provided by default
    with the WASD server is extremely dangerous. I will not name it to avoid
    helping too much the script kiddies, so in doubt remove everything
    unless you know that you absolutely need it.

    If the machine hosting the web server has some untrusted users with
    local accounts on the machine, then forbid execution of arbitrary cgi
    scripts in ~untrusted/cgi-bin with a rule such as:
       fail /~untrusted/cgi-bin/*
    put _before_ the rule
       exec /~*/cgi-bin/* /user_disk/*/cgi-bin/*
    or better, block cgi access to all local users.

  5.6 Never run cgi scripts under the account of a privileged user

    If you really need privileges in your cgi script, then force the
    https protocol and force user authentication. Read the WASD documents
    http://wasd.vsm.com.au/ht_root/doc/htd/htd_1200.html
    Never do user authentication without SSL (the https protocol).

    Do not run cgi scripts as user http$server. Strictly speaking, this
    account is not privileged, but since it is also used to run the main
    server, faulty cgi scripts can cause more harm than totally
    unprivileged users.

    If the machine hosting the web servers has untrusted local
    users with a ~username/cgi-bin directory, then it is preferable to
    either remove the ability to run scripts there, or at least run the
    scripts as the user. Running those scripts as user http$server
    lets the untrusted users do many things to the web server, such
    as reading the server logs if ACLs are not set correctly, or killing
    the main server process; it would be the equivalent of giving
    the additional right [http$server] to the untrusted users.


6. Examples of site weaknesses

  Several WASD sites were used for testing the various weaknesses. An actual
  intrusion was made on two systems only to check that it was indeed feasible.
  The system administrators were warned immediately. On other systems
  the presence of the vulnerabilities was checked but was not used for
  intrusion.

  6.1 Site A

    The first system compromise was not entirely due to weaknesses in WASD
    and was only possible because of a flaw in an independent cgi script
    which is not part of the WASD distribution.  However without the WASD
    vulnerabilities, the faulty script would not have been found and its
    source analysed to find the weakness.

    The system was rather well (but not perfectly) configured. But the
    system administrator had left a faulty script in his cgi-bin directory.
    The home directory was correctly protected by ACLs so even the WASD
    vulnerabilities didn't allow reading it. The list of scripts and their
    sources were supposed to be protected by the WASD configuration, but
    it was very easy to work around this using the "upd" and the "extract"
    builtin scripts as described in section 4.2.7.

    There was an another weakness in the WASD configuration: the script was
    run under the identity of the owner of the script, which was the system
    administrator. This account was not the predefined SYSTEM account but
    still had many privileges. It was then possible to remotely run any
    command with those privileges. The system administrator was told
    how the compromise was done and how to fix the server.

  6.2 Site B

    The story is very similar, but in this case a flaw in one of the scripts
    provided by WASD was used. The flaw was particularly severe because the
    particular configuration used at this site allowed some scripts to be run
    under the identity of a system administrator, who had all privileges
    (SETPRV, which is the equivalent of root). The system administrators
    were warned about the flaw and fixed it immediately.

  6.3 Sites C,D,E

    On three different sites, all directories and files were owned by the
    user which runs all cgi scripts. So these sites were particularly
    vulnerable: any flaw in a scrit can immediately lead to a SYSTEM
    compromise because the script has write access to everything. The
    system administrators have been warned and the sites have been fixed.

  6.4 Almost all sites

    In almost all tested sites, it was very easy to get read access to
    important configuration files that are supposed to stay confidential,
    and to get the list and sources of all cgi scripts, including site
    specific scripts.


7. Conclusion

  Do not blindly believe that, if something runs on OpenVMS, then it must
  be secure. Common sense precautions such as not giving away the entire
  server tree or all script sources, and checking user input in all cgi
  scripts, must be taken even on OpenVMS.

  If you are using WASD 8.0 or earlier, fix your configuration *immediately*.

Jean-loup Gailly

http://gailly.net
PGP or GPG key: http://jl.gailly.net/jloup.asc
PGP sig: E3EC F4DF 7EDB E724 A3EC  FBC2 D9A2 7D25 0196 71A7

Questions about the WASD server should be sent to its author Mark Daniel
<Mark.Daniel@wasd.vsm.com.au>. Questions about this advisory should be
sent to Jean-loup Gailly <jloup@gailly.net>


8. Acknowledgments

  Thanks to Mark Daniel, author of the WASD server, for making it free
  software, for quickly answering to my initial report, and for working
  insane hours to fix all the problems I reported.

  Thanks to Beave and Doc Cypher for providing free accounts on their
  respective OpenVMS servers, for testing the proposed solutions and
  suggesting improvements.

  Thanks to Jeremy Begg for hosting the WASD demonstration server.


9. Document history

 - Sept. 16, 2002: draft 0.1, WASD vendor contacted
 - Sept. 16, 2002: draft 0.2, added section "don't run cgi as trusted user"
 - Sept. 19, 2002: draft 0.3  
   . mention the possibility of remote SYSTEM compromise
   . added disclosure of full physical path in 4.2.2
   . added directory traversal with glist.com in 4.2.6
   . added section 4.3 "CGI scripts are run under the identity of the server"
 - Sept. 23, 2002: CERT contacted
 - Sept. 25, 2002: version 1.0. Added reference to WASD advisory in 5.1
 - Sept. 25, 2002: Info-WASD mailing list informed
 - Sept. 26, 2002: sent to Bugtraq for publication

This document is available at
  http://jl.gailly.net/security/wasd-vuln-2002-09.txt
It is provided under the policy documented at
  http://www.wiretrip.net/rfp/policy.html

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9kYF02aJ9JQGWcacRAiZSAJ9StmBUBUYnWC+Smnq5ZzC7EsrolQCfYeSX
LVJofzQzIUzriquN6J847GM=
=F2B9
-----END PGP SIGNATURE-----

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

Copyright 2017, SecurityGlobal.net LLC