WASD Package Security Advisory ------------------------------ Release 1.1 27 Sep 2002 ----------------------- 0. Contents 1. Introduction 2. Severity: HIGH 3. Vulnerable Versions 4. Description 5. Solutions 6. New Structure 7. Fix Kit 9. Configuration Guidelines 9. Implications 10. Conclusion 11. Acknowledgements 12. Published Information 1. Introduction - YOU MUST APPLY FIXES - This is MANDATORY UPDATE advice. All sites are at least potentially vulnerable to some or all of the issues described in this and related documents (see "13. Published Information"). An online invitation to hack VMS and its software environment has produced some results. A demonstration of several significant vulnerabilities in the WASD package and some installations, and a report containing details provided to the WASD author and selected site administrators. The advisory you are currently reading was originally posted to the info-WASD mailing list. It is also being placed into the [DOC.MISC] directory where all can read it again as as a reminder of and warning about about site security and complacency. This document provides a brief overview of the vulnerabilities uncovered, the proposed solutions, both immediate, in ensuring the security of existing installations, and in the longer term in providing a structure that is resistant to compromise. Vulnerabilities comprise four main issues: 1.1 The ability to use VMS file system parent directory syntax in URLs to traverse path trees in a compromising fashion. 1.2 A default WASD installation that does not control access to configuration and other sensitive data. The example configuration files provide too liberal a site configuration allowing easy access to site environment information. 1.3 A 'classic' exploit in one example script uses non validated form data. 1.4 Server capabilities, that although not available by default, once enabled and not sufficiently evaluated or maintained pose a significant threat to server and system integrity. The author of the vulnerability information will publish a Bugtraq advisory concurrently with the publication this WASD advisory. The Bugtraq advisory will have significant detail not included in this advice. See section "13. Published Information" for availability. 2. Severity: HIGH Information leakage in default configuration and installation provides a source of system and environment information for designing specific compromises. A combination of disparate vulnerabilities with the deployment of a specific capability could result in a privilege compromise. 3. Vulnerable Versions All WASD versions up to and including version 8.0. Demonstrated on version 7.1, 7.2 and 8.0. 4. Description "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." Technical Overview, section 6.1 (ironically entitled) 'Securing the Site' 4.1 Default configuration files derived from the [EXAMPLES] directory are designed to 'show off' the package's capabilities. Many of these capabilities allow information sensitive in hostile environments to be viewed or inferred. 4.2 The installation procedure is not rigorous enough in ensuring the package directory tree is protected from changes by a compromised server. This results in some sites being at particular risk from a script vulnerability. Installation also does not apply an appropriate file system access control schema on areas containing potentially sensitive information. 4.3 A server implementation 'loophole' allowing VMS parent directory syntax to be introduced from request URLs effectively subvert access controls on URL paths. This allows access to directories thought to be protected by access controls through instructing the file system to move 'up and behind' them. Several sites were investigated by the author of the vulnerability report. All were far too liberal in directory tree access control, all exhibited severe configuration and environment information leakage, and a disproportionate number had configuration issues sufficient to allow an external agent to introduce or change file system contents! 5.0 Solutions Many WASD vulnerabilities were inherent to the package's default directory structure and access permissions (file protection) schema. Others relied on the server's parent directory syntax 'loophole'. Still others could derive the same or similar information by using example scripts. Script vulnerabilities have an obvious need for closure. Provide a reduction in the potential for dangerous site misconfiguration and alert of the site administrator to such events occurring. Update packages for v7.2 and 8.0 with a fixed and enhanced server are available from the WASD download site. The INSTALL_SECURE.COM procedure will allow relatively straight-forward site migration to the new directory structure and permission schema. This procedure is available separately from the WASD download site. Some of the these listed solutions are enhancements on basic fix requirements, designed to improve the requirement from 'just enough' to providing additional useful functionality related to the issue. 5.1 As many vulnerabilities are due to the package directory schema and permissions a revised directory structure allowing appropriate protections for directories containing sensitive files (such as configuration, script source, logs) must be established. This should be amenable to straight-forward migration from the existing structure. The INSTALL_SECURE.COM procedure, initially supplied as a standalone script, can be used to migrate from any 7.n, 8.n (and possibly even 6.n) installation. Releases 8.1 and later will use this directory structure by default. 5.2 All parts of the package tree should be owned by a non-server account with WORLD read access and only provide other required server account access via ACLs. All files in the package tree will be owned by SYSTEM. 5.3 The server parent directory syntax 'loophole' has been closed. This new code baseline is available using the v7.2.4 or v8.0.1 update packages. (Of course this issue will remain closed for versions 8.1 and onwards.) 5.4 Changes to server PERSONA scripting making it more difficult to inadvertently map a privileged account. 5.5 Additional OPCOM reporting and statistic counters for PERSONA scripting note failed PERSONA attempts and PERSONA creation of privileged scripts. 5.6 Additional report mapping directives that allow 4nn reports to be mapped to and from one another. For example, a document not found (404) could be mapped to a forbidden report (403) or vice versa. 5.7 Configuration guidelines to reduce or eliminate information leakage. Although having been recommendations for some time now they will now be implemented as installation defaults, in future requiring a site to electively be made more liberal rather than more restrictive. Section "8. Configuration Guidelines" provide these for applying to existing sites. 5.8 All scripts should not be made available on any given site without some thought being given to unexpected uses. Scripts with such potential might best be under some access control (authorization) so that accountability can also be established. Scripts with known potential for such use will progressively be modified to restrict or place such activities under some control. 5.8 The specific script with the exploitable vulnerability should be disabled. The INSTALL_SECURE.COM procedure performs this inherently both by making it inaccessible and also eliminating possible package tree ownership issues. 6. New Structure A new directory structure has been implemented. The purpose of this is to better partition various components of an installed site. Package delivered tools and scripts from those available to the server for execution. Configuration files from other server environment files (e.g. startup). Directory Comment Access Purpose --------- ------- ------ ------- [AXP-BIN] new execute Alpha script executables [AXP] existing none Alpha deliverable and tools [CGI-BIN] new execute architecture neutral scripts [DOC] existing read documentation [EXAMPLE] existing read example configurations, etc. [EXERCISE] existing read tests, performance data, etc. [HTTP$SERVER] existing none server account home [JAVA] existing read+exec Java classes [LOCAL] existing none configuration files [LOG] existing none server access logs [LOG_SERVER] new write server process logs [RUNTIME] existing read runtime images, help pages, etc. [SCRATCH] existing write script scratch space [SCRIPT] existing none script deliverables [SCRIPT_LOCAL] existing none site script locale [SRC] existing read package source tree [VAX-BIN] new execute VAX script executables [VAX] existing none VAX deliverables and tools The new CGI-BIN logical will be defined as [CGI-BIN],[AXP-BIN]/[VAX-BIN],[JAVA] instead of [SCRIPT_LOCAL],[SCRIPT],[AXP]/[VAX],[JAVA]. The [AXP] and [VAX] directories will continue to be used as build targets and for containing the server image and tools such as HTTPDMON. Scripts that formerly used $HT_EXE: to activate script executables will now need to use $CGI-BIN:[000000]. Site administrators must place scripts into [CGI-BIN] and/or [AXP-BIN]/[VAX-BIN] as appropriate (or use mapping rules into their own directory structures). Scripts that may have used HT_ROOT:[LOG.SERVER] for scratch space should now use HT_SCRATCH: or HT_ROOT:[SCRATCH]. 7. Fix Kit The WASD download site http://wasd.vsm.com.au/wasd/ should have update kits available. Version 7.2.4 or later, version 8.0.1 or later. There should be an INSTALL_SECURE kit as well. 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 INSTALL_SECURE tool is initially being supplied separately to allow for updating if deficiencies or unexpected side effects are reported. It will be integrated into the main WASD distribution with the next major release as part of the installation procedures and will be able to be used subsequent to installation to revalidate a site's structure. 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) Although the migration kit and update server baseline has been tested on a number of sites before release it has by necessity been through a rather more limited qualification period and process than usual. In other words, although every endeavour has been made to ensure it works, there is a small chance it may damage your site. It assumes an out-of-the-box WASD installation. Please ensure you can recover from any mishap by having a recent and readily available backup of the installation at your disposal. 8. Configuration Guidelines These specific guidelines should be followed to reduce the incidence and risk of information leakage. They are included here so that their function and implications can be emphasized within the security context of this document. These guidelines are also described and recommended in the Technical Overview, section 6.1 'Securing the Site'. Although these recommendations apply to a greater or lesser extent on intranets they are MANDATORY on publicly accessible sites (the Internet). They will also be the defaults in future WASD releases. Some of these guidelines apply to version 8.0 and later only. 8.1 Do not place the site document tree inside the package tree. This allows the package to be completely quarantined from the site information if desired. 8.2 Ensure the package tree has the recommended directory and file protections in place. 8.3 Disable "forced" directory listings (those where supplying a wildcard file specification always results in an "Index of" page). # HTTPD$CONFIG [DirWildcard] disabled Limited portions of the served tree can have this selectively enabled using mapping rules if required. # HTTPD$MAP (v8.n only) set /part/of/tree/* dir=wildcard 8.4 Some Web security guidelines argue that listings should never be generated. # HTTPD$CONFIG [DirAccess] disabled Again, selected portions of the served tree can have this enabled using mapping rules if required. # HTTPD$MAP (v8.n only) set /part/of/tree/* dir=access 8.5 Remove information about the underlying VMS file system. Error reports, directory listings and some other facilities include the corresponding VMS file system specification and/or error status values. # HTTPD$CONFIG [DirMetaInfo] disabled [ReportMetaInfo] disabled 8.6 Reduce the detail in information provided in error and other reports (i.e. obscure the real reason for the server refusing the request). For instance, WASD reports a difference between document-not-found and document-protected. Often this give information about what exists even if nothing of it's content. # HTTPD$CONFIG [ReportBasicOnly] enabled [ServerSignature] disabled More detailed reports may be enabled for selected parts of the site using mapping rules. # HTTPD$MAP set /part/of/tree/* report=detailed set /part/of/tree/* report=basic It is possible to map 400 class status messages between each other. For example, all file-not-founds can be represented as permission-denied by using the first example, the converse by using the second, etc. # HTTPD$MAP set * report=400=403 set * report=404=403 set * report=403=404 8.7 The VMS ellipsis wildcard ("...") also proved to have some implications when combined with certain scripts. It has been disabled by default but can be selectively reenabled using a mapping rule. # HTTPD$MAP set /part/of/tree/* map=ellipsis 8.8 Disable or control convenience facilities provided by 'internal' scripts. o /WHERE This 'script' give a VMS file specification (mapped) for the supplied path. Helpful for some environments, dangerous for others. Disable by removing the mapping rule that identifies it as a script. # HTTPD$MAP ## script /where/* /where/* For v8.n it can be conditionally mapped for use if desired. This allows it to be selectively available for only some paths. # HTTPD$MAP if (path-info:"/where/ht_root/*") script /where/* /where/* endif Of course the condition tested can be any appropriate request characteristic. o /UPD This 'script' provides a rudimentary site navigation and update tool intended for site administration ad hoc changes. Again helpful in some, dangerous in others. Disable or selectively enable (v8.0) in the same manner as for /WHERE # HTTPD$MAP ## script /upd/* /upd/* o /TREE Is an 'internal' script that provides a character-cell graphical representation of the directory tree below the path supplied in the request URL. Again it may reveal information that could be valuable in assessing a site. Disable completely or selectively enable (v8.0) for specific requests. # HTTPD$MAP if (path-info:"/tree/sys$common/syshlp/*") script /tree/* /tree/* endif 8.9 Be very careful when designing and deploying scripts. Do not deploy scripts unless you understand their behaviours. Do not deploy scripts that use command line substitutions. Do not deploy scripts that provide unfettered environment information. Do not change package directory protections to allow scripts to access their contents. However unlikely it might appear scripting can be disabled completely, perhaps reducing the chance for site compromise to zero. # HTTPD$CONFIG [Scripting] disabled 8.10 Do not execute scripts by mapping the PERSONAs of privileged accounts. Indeed, with 7.2.4 and 8.0.1 it is no longer possible without server startup changes. The basic /PERSONA qualifier no longer allows mapping to privileged accounts. Additional changes to PERSONA allow for more controlled application. o /PERSONA allows (only) unprivileged, active accounts to script o /PERSONA=AUTHORIZED allows unprivileged accounts to script ONLY if the request is subject to HTTP authorization o /PERSONA=RELAXED in addition to unprivileged accounts allows privileged ones to script o /PERSONA=(RELAXED=AUTHORIZED) in addition to unprivileged accounts allows privileged ones to script if the request is subject to HTTP authorization o /PERSONA=(AUTHORIZED,RELAXED) allows unprivileged and privileged accounts to script but only if the request was subject to authorization If you must script with privileged accounts be very, VERY careful in script design, application of the script=as= rule to that script only, make the script subject to authorization, be rigorous in testing, and monitor activity. Better still, DON'T DO IT! OPCOM now reports every privileged PERSONA created for scripting. 8.11 Site administrators that maintain their own scripting areas should follow the same basic permission structure as that implemented by INSTALL_SECURE.COM. 10. Implications After applying the fix and updates, and restricting server configuration WASD will be a demonstrably more secure environment for public access. These will also have the effect of making the package less friendly to the (genuine) user and to site administration in general (for example, it's more informative and useful to be told of a file protection violation than a file not being found, but that's part of the problem in a hostile environment). Some scripts and other tools will cease to work in this environment. Due to time constraints in addressing the vulnerability issues these have not yet been modified but will be in forthcoming releases. The package will not be quite as amenable to demonstrating it's full capabilities. These changes are expected to be sufficient to secure the installation and will be the directory structure and environment implemented for new installation from version 8.1 onwards. 11. Conclusion Don't drag your applications from relatively benign into relatively hostile environments without giving sufficient consideration to the new demands placed on them. The WASD environment was sufficiently well structured to allow a rapid and moderately non intrusive migration to a more secure configuration. WASD had many configuration options available that would have reduced sites' exposure if enabled. These were not by default. Start conservative and liberalize as necessary, not the other way around. It is expected that existing sites that apply these changes will remove all known vulnerabilities. Future upgrades will maintain this changed environment and so these should be relatively straight-forward. 12. Acknowledgements First and foremost to: Jean-loup Gailly http://gailly.net without whom all of this would not have been possible. And yes, I understand that this is a left-handed compliment. Yet, as the author (perhaps some will now say perpetrator) of the WASD package, I am indebted to Gailly not only for his professional conduct in demonstrating the deficiencies and allowing for a considered response to be formulated, but also for the considerable time and effort he has expended in providing assistance in identifying issues and suggesting possible solutions. Also, in particular, to: Doc Cypher cypher althacker cjb net> http://vmsbox.cjb.net/ who runs a free VMS account service to all those who would like a taste of the DCL command line. Doc's site was one initially probed. And then to several other WASD sites out there who experienced the alarming experience of a notice of potential compromise. Thanks for not running out and immediately installing Apache on all your VAXes folks :^) Finally to my wonderful spouse who has not seen me evenings these past ten days without so much as a single grumble. As a matter of fact I'll be glad to get this out of the way before she gets to like it too much! 13. Published Information o Original advisory put together by Jean-loup Gailly http://jl.gailly.net/security/wasd-vuln-2002-09.txt o Bugtraq advisory http://online.securityfocus.com/archive/1/293229 o This 'WASD Package Security Advisory' http://wasd.vsm.com.au/ht_root/doc/misc/wasd_advisory_020925.txt Document History Mark G.Daniel o 25 Sep 2002, initial draft o 27 Sep 2002, added Bugtraq reference