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