5 WASD Package Security Advisory5 ------------------------------1 Release 1.1 27 Sep 20021 ----------------------- 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 Information1. Introduction- YOU MUST APPLY FIXES - This is MANDATORY UPDATE advice.JAll sites are at least potentially vulnerable to some or all of the issuesJdescribed in this and related documents (see "13. Published Information").JAn online invitation to hack VMS and its software environment has producedLsome results. A demonstration of several significant vulnerabilities in theMWASD package and some installations, and a report containing details providedJto the WASD author and selected site administrators. The advisory you areMcurrently reading was originally posted to the info-WASD mailing list. It isKalso being placed into the [DOC.MISC] directory where all can read it againJas as a reminder of and warning about about site security and complacency.MThis document provides a brief overview of the vulnerabilities uncovered, theHproposed solutions, both immediate, in ensuring the security of existingFinstallations, and in the longer term in providing a structure that isresistant to compromise.*Vulnerabilities comprise four main issues:J1.1 The ability to use VMS file system parent directory syntax in URLs to.traverse path trees in a compromising fashion.N1.2 A default WASD installation that does not control access to configurationNand other sensitive data. The example configuration files provide too liberalJa site configuration allowing easy access to site environment information.L1.3 A 'classic' exploit in one example script uses non validated form data.N1.4 Server capabilities, that although not available by default, once enabledIand not sufficiently evaluated or maintained pose a significant threat toserver and system integrity.KThe author of the vulnerability information will publish a Bugtraq advisoryKconcurrently with the publication this WASD advisory. The Bugtraq advisoryKwill have significant detail not included in this advice. See section "13.(Published Information" for availability.2. Severity: HIGHOInformation leakage in default configuration and installation provides a sourceIof system and environment information for designing specific compromises.LA combination of disparate vulnerabilities with the deployment of a specific2capability could result in a privilege compromise.3. Vulnerable Versions2All WASD versions up to and including version 8.0.)Demonstrated on version 7.1, 7.2 and 8.0.4. DescriptionM"The default configuration is fairly liberal, providing information of use inNa 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'J4.1 Default configuration files derived from the [EXAMPLES] directory areNdesigned to 'show off' the package's capabilities. Many of these capabilitiesMallow information sensitive in hostile environments to be viewed or inferred.N4.2 The installation procedure is not rigorous enough in ensuring the packageOdirectory tree is protected from changes by a compromised server. This resultsDin some sites being at particular risk from a script vulnerability. JInstallation also does not apply an appropriate file system access control=schema on areas containing potentially sensitive information.O4.3 A server implementation 'loophole' allowing VMS parent directory syntax toJbe introduced from request URLs effectively subvert access controls on URLKpaths. This allows access to directories thought to be protected by accessJcontrols through instructing the file system to move 'up and behind' them.OSeveral sites were investigated by the author of the vulnerability report. AllKwere far too liberal in directory tree access control, all exhibited severeIconfiguration and environment information leakage, and a disproportionateHnumber had configuration issues sufficient to allow an external agent to)introduce or change file system contents!5.0 SolutionsJMany WASD vulnerabilities were inherent to the package's default directoryLstructure and access permissions (file protection) schema. Others relied onOthe server's parent directory syntax 'loophole'. Still others could derive theMsame or similar information by using example scripts. Script vulnerabilitiesKhave an obvious need for closure. Provide a reduction in the potential forKdangerous site misconfiguration and alert of the site administrator to suchevents occurring.OUpdate packages for v7.2 and 8.0 with a fixed and enhanced server are availablefrom the WASD download site.LThe INSTALL_SECURE.COM procedure will allow relatively straight-forward siteOmigration to the new directory structure and permission schema. This procedure4is available separately from the WASD download site.NSome of the these listed solutions are enhancements on basic fix requirements,Ndesigned to improve the requirement from 'just enough' to providing additional*useful functionality related to the issue.H5.1 As many vulnerabilities are due to the package directory schema andNpermissions a revised directory structure allowing appropriate protections forMdirectories containing sensitive files (such as configuration, script source,Glogs) must be established. This should be amenable to straight-forwardImigration from the existing structure. The INSTALL_SECURE.COM procedure,Oinitially supplied as a standalone script, can be used to migrate from any 7.n,O8.n (and possibly even 6.n) installation. Releases 8.1 and later will use thisdirectory structure by default.O5.2 All parts of the package tree should be owned by a non-server account withKWORLD read access and only provide other required server account access via=ACLs. All files in the package tree will be owned by SYSTEM.C5.3 The server parent directory syntax 'loophole' has been closed.PThis 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.)D5.4 Changes to server PERSONA scripting making it more difficult to'inadvertently map a privileged account.L5.5 Additional OPCOM reporting and statistic counters for PERSONA scriptingHnote failed PERSONA attempts and PERSONA creation of privileged scripts.M5.6 Additional report mapping directives that allow 4nn reports to be mappedJto and from one another. For example, a document not found (404) could be1mapped to a forbidden report (403) or vice versa.I5.7 Configuration guidelines to reduce or eliminate information leakage.GAlthough having been recommendations for some time now they will now beNimplemented as installation defaults, in future requiring a site to electivelyMbe made more liberal rather than more restrictive. Section "8. Configuration9Guidelines" provide these for applying to existing sites.L5.8 All scripts should not be made available on any given site without someOthought being given to unexpected uses. Scripts with such potential might bestObe under some access control (authorization) so that accountability can also beMestablished. Scripts with known potential for such use will progressively beAmodified to restrict or place such activities under some control.P5.8 The specific script with the exploitable vulnerability should be disabled. KThe INSTALL_SECURE.COM procedure performs this inherently both by making itIinaccessible and also eliminating possible package tree ownership issues.6. New StructureJA new directory structure has been implemented. The purpose of this is toLbetter partition various components of an installed site. Package deliveredDtools and scripts from those available to the server for execution. GConfiguration files from other server environment files (e.g. startup).2 Directory Comment Access Purpose2 --------- ------- ------ -------C [AXP-BIN] new execute Alpha script executablesF [AXP] existing none Alpha deliverable and toolsG [CGI-BIN] new execute architecture neutral scripts8 [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 executablesE [VAX] existing none VAX deliverables and toolsOThe new CGI-BIN logical will be defined as [CGI-BIN],[AXP-BIN]/[VAX-BIN],[JAVA]Kinstead of [SCRIPT_LOCAL],[SCRIPT],[AXP]/[VAX],[JAVA]. The [AXP] and [VAX]Ldirectories will continue to be used as build targets and for containing theMserver image and tools such as HTTPDMON. Scripts that formerly used $HT_EXE:Lto activate script executables will now need to use $CGI-BIN:[000000]. SiteNadministrators must place scripts into [CGI-BIN] and/or [AXP-BIN]/[VAX-BIN] asHappropriate (or use mapping rules into their own directory structures). LScripts that may have used HT_ROOT:[LOG.SERVER] for scratch space should now%use HT_SCRATCH: or HT_ROOT:[SCRATCH]. 7. Fix KitThe WASD download site http://wasd.vsm.com.au/wasd/Lshould have update kits available. Version 7.2.4 or later, version 8.0.1 orKlater. There should be an INSTALL_SECURE kit as well. Sites with versionsGearlier than 7.2 are encouraged to update to at least 7.2, although theNINSTALL_SECURE procedure can be applied alone with significant improvements to3site security (but without the server image fixes).KThe INSTALL_SECURE tool is initially being supplied separately to allow forMupdating if deficiencies or unexpected side effects are reported. It will beNintegrated into the main WASD distribution with the next major release as partHof 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 activitiesI (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)JAlthough the migration kit and update server baseline has been tested on aMnumber of sites before release it has by necessity been through a rather moreNlimited qualification period and process than usual. In other words, althoughLevery endeavour has been made to ensure it works, there is a small chance itNmay damage your site. It assumes an out-of-the-box WASD installation. PleaseEensure you can recover from any mishap by having a recent and readily6available backup of the installation at your disposal.8. Configuration GuidelinesMThese specific guidelines should be followed to reduce the incidence and riskJof information leakage. They are included here so that their function andMimplications can be emphasized within the security context of this document. NThese guidelines are also described and recommended in the Technical Overview,Ksection 6.1 'Securing the Site'. Although these recommendations apply to aDgreater or lesser extent on intranets they are MANDATORY on publiclyNaccessible sites (the Internet). They will also be the defaults in future WASDHreleases. Some of these guidelines apply to version 8.0 and later only.N8.1 Do not place the site document tree inside the package tree. This allowsNthe package to be completely quarantined from the site information if desired.O8.2 Ensure the package tree has the recommended directory and file protections in place.O8.3 Disable "forced" directory listings (those where supplying a wildcard file4specification always results in an "Index of" page). # HTTPD$CONFIG [DirWildcard] disabledKLimited portions of the served tree can have this selectively enabled usingmapping rules if required. # HTTPD$MAP (v8.n only)" set /part/of/tree/* dir=wildcardE8.4 Some Web security guidelines argue that listings should never be generated. # HTTPD$CONFIG [DirAccess] disabledOAgain, selected portions of the served tree can have this enabled using mappingrules if required. # HTTPD$MAP (v8.n only) set /part/of/tree/* dir=accessM8.5 Remove information about the underlying VMS file system. Error reports,Jdirectory listings and some other facilities include the corresponding VMS5file system specification and/or error status values. # HTTPD$CONFIG [DirMetaInfo] disabled [ReportMetaInfo] disabledO8.6 Reduce the detail in information provided in error and other reports (i.e.Lobscure the real reason for the server refusing the request). For instance,MWASD reports a difference between document-not-found and document-protected. NOften this give information about what exists even if nothing of it's content. # HTTPD$CONFIG [ReportBasicOnly] enabled [ServerSignature] disabledIMore detailed reports may be enabled for selected parts of the site usingmapping rules. # HTTPD$MAP% set /part/of/tree/* report=detailed" set /part/of/tree/* report=basicHIt is possible to map 400 class status messages between each other. ForMexample, all file-not-founds can be represented as permission-denied by using9the first example, the converse by using the second, etc. # HTTPD$MAP set * report=400=403 set * report=404=403 set * report=403=404L8.7 The VMS ellipsis wildcard ("...") also proved to have some implicationsOwhen 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=ellipsisN8.8 Disable or control convenience facilities provided by 'internal' scripts. o /WHEREJ This 'script' give a VMS file specification (mapped) for the suppliedI path. Helpful for some environments, dangerous for others. DisableA 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/* endifB Of course the condition tested can be any appropriate request characteristic. o /UPDD This 'script' provides a rudimentary site navigation and updateA tool intended for site administration ad hoc changes. AgainB 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 /TREEE Is an 'internal' script that provides a character-cell graphicalD 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$MAP2 if (path-info:"/tree/sys$common/syshlp/*")! script /tree/* /tree/* endifI8.9 Be very careful when designing and deploying scripts. Do not deployOscripts unless you understand their behaviours. Do not deploy scripts that useJcommand line substitutions. Do not deploy scripts that provide unfetteredNenvironment information. Do not change package directory protections to allow!scripts to access their contents.NHowever unlikely it might appear scripting can be disabled completely, perhaps0reducing the chance for site compromise to zero. # HTTPD$CONFIG [Scripting] disabled M8.10 Do not execute scripts by mapping the PERSONAs of privileged accounts. LIndeed, with 7.2.4 and 8.0.1 it is no longer possible without server startupMchanges. The basic /PERSONA qualifier no longer allows mapping to privilegedOaccounts. 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=RELAXEDJ 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 authorizationKIf you must script with privileged accounts be very, VERY careful in scriptOdesign, application of the script=as= rule to that script only, make the scriptOsubject to authorization, be rigorous in testing, and monitor activity. Betterstill, DON'T DO IT!AOPCOM now reports every privileged PERSONA created for scripting.O8.11 Site administrators that maintain their own scripting areas should followNthe same basic permission structure as that implemented by INSTALL_SECURE.COM.10. ImplicationsMAfter applying the fix and updates, and restricting server configuration WASDMwill be a demonstrably more secure environment for public access. These willNalso have the effect of making the package less friendly to the (genuine) userMand to site administration in general (for example, it's more informative andMuseful to be told of a file protection violation than a file not being found,9but that's part of the problem in a hostile environment).LSome scripts and other tools will cease to work in this environment. Due toOtime constraints in addressing the vulnerability issues these have not yet been-modified but will be in forthcoming releases.DThe package will not be quite as amenable to demonstrating it's full capabilities.OThese changes are expected to be sufficient to secure the installation and willKbe the directory structure and environment implemented for new installationfrom version 8.1 onwards.11. ConclusionKDon't drag your applications from relatively benign into relatively hostileNenvironments without giving sufficient consideration to the new demands placedon them.JThe WASD environment was sufficiently well structured to allow a rapid andBmoderately non intrusive migration to a more secure configuration.EWASD had many configuration options available that would have reducedOsites' exposure if enabled. These were not by default. Start conservative and2liberalize as necessary, not the other way around.KIt is expected that existing sites that apply these changes will remove allNknown vulnerabilities. Future upgrades will maintain this changed environment3and so these should be relatively straight-forward.12. Acknowledgements(First and foremost to: Jean-loup Gailly* * http://gailly.net Mwithout whom all of this would not have been possible. And yes, I understandMthat this is a left-handed compliment. Yet, as the author (perhaps some willNnow say perpetrator) of the WASD package, I am indebted to Gailly not only forMhis professional conduct in demonstrating the deficiencies and allowing for aLconsidered response to be formulated, but also for the considerable time andHeffort he has expended in providing assistance in identifying issues andsuggesting possible solutions.$Also, in particular, to: Doc CypherO cypher althacker cjb net>0 http://vmsbox.cjb.net/Nwho runs a free VMS account service to all those who would like a taste of the7DCL command line. Doc's site was one initially probed.KAnd then to several other WASD sites out there who experienced the alarmingOexperience of a notice of potential compromise. Thanks for not running out and9immediately installing Apache on all your VAXes folks :^)PFinally to my wonderful spouse who has not seen me evenings these past ten days Mwithout so much as a single grumble. As a matter of fact I'll be glad to get8this out of the way before she gets to like it too much!13. Published Information7 o Original advisory put together by Jean-loup Gailly8 http://jl.gailly.net/security/wasd-vuln-2002-09.txt o Bugtraq advisory5 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.txtDocument History Mark G.Daniel  o 25 Sep 2002, initial draft) o 27 Sep 2002, added Bugtraq reference