[0001]
[0002]
[0003]
[0004]
[0005]
[0006]
[0007]
[0008]
[0009]
[0010]
[0011]
[0012]
[0013]
[0014]
[0015]
[0016]
[0017]
[0018]
[0019]
[0020]
[0021]
[0022]
[0023]
[0024]
[0025]
[0026]
[0027]
[0028]
[0029]
[0030]
[0031]
[0032]
[0033]
[0034]
[0035]
[0036]
[0037]
[0038]
[0039]
[0040]
[0041]
[0042]
[0043]
[0044]
[0045]
[0046]
[0047]
[0048]
[0049]
[0050]
[0051]
[0052]
[0053]
[0054]
[0055]
[0056]
[0057]
[0058]
[0059]
[0060]
[0061]
[0062]
[0063]
[0064]
[0065]
[0066]
[0067]
[0068]
[0069]
[0070]
[0071]
[0072]
[0073]
[0074]
[0075]
[0076]
[0077]
[0078]
[0079]
[0080]
[0081]
[0082]
[0083]
[0084]
[0085]
[0086]
[0087]
[0088]
[0089]
[0090]
[0091]
[0092]
[0093]
[0094]
[0095]
[0096]
[0097]
[0098]
[0099]
[0100]
[0101]
[0102]
[0103]
[0104]
[0105]
[0106]
[0107]
[0108]
[0109]
[0110]
[0111]
[0112]
[0113]
[0114]
[0115]
[0116]
[0117]
[0118]
[0119]
[0120]
[0121]
[0122]
[0123]
[0124]
[0125]
[0126]
[0127]
[0128]
[0129]
[0130]
[0131]
[0132]
[0133]
[0134]
[0135]
[0136]
[0137]
[0138]
[0139]
[0140]
[0141]
[0142]
[0143]
[0144]
[0145]
[0146]
[0147]
[0148]
[0149]
[0150]
[0151]
[0152]
[0153]
[0154]
[0155]
[0156]
[0157]
[0158]
[0159]
[0160]
[0161]
[0162]
[0163]
[0164]
[0165]
[0166]
[0167]
[0168]
[0169]
[0170]
[0171]
[0172]
[0173]
[0174]
[0175]
[0176]
[0177]
[0178]
[0179]
[0180]
[0181]
[0182]
[0183]
[0184]
[0185]
[0186]
[0187]
[0188]
[0189]
[0190]
[0191]
[0192]
[0193]
[0194]
[0195]
[0196]
[0197]
[0198]
[0199]
[0200]
[0201]
[0202]
[0203]
[0204]
[0205]
[0206]
[0207]
[0208]
[0209]
[0210]
[0211]
[0212]
[0213]
[0214]
[0215]
[0216]
[0217]
[0218]
[0219]
[0220]
[0221]
[0222]
[0223]
[0224]
[0225]
[0226]
[0227]
[0228]
[0229]
[0230]
[0231]
[0232]
[0233]
[0234]
[0235]
[0236]
[0237]
[0238]
[0239]
[0240]
[0241]
[0242]
[0243]
[0244]
[0245]
[0246]
[0247]
[0248]
[0249]
[0250]
[0251]
[0252]
[0253]
[0254]
[0255]
[0256]
[0257]
[0258]
[0259]
[0260]
[0261]
[0262]
[0263]
[0264]
[0265]
[0266]
[0267]
[0268]
[0269]
[0270]
[0271]
[0272]
[0273]
[0274]
[0275]
[0276]
[0277]
[0278]
[0279]
[0280]
[0281]
[0282]
[0283]
[0284]
[0285]
[0286]
[0287]
[0288]
[0289]
[0290]
[0291]
[0292]
[0293]
[0294]
[0295]
[0296]
[0297]
[0298]
[0299]
[0300]
[0301]
[0302]
[0303]
[0304]
[0305]
[0306]
[0307]
[0308]
[0309]
[0310]
[0311]
[0312]
[0313]
[0314]
[0315]
[0316]
[0317]
[0318]
[0319]
[0320]
[0321]
[0322]
[0323]
[0324]
[0325]
[0326]
[0327]
[0328]
[0329]
[0330]
[0331]
[0332]
[0333]
[0334]
[0335]
[0336]
[0337]
[0338]
[0339]
[0340]
[0341]
[0342]
[0343]
[0344]
[0345]
[0346]
[0347]
[0348]
[0349]
[0350]
[0351]
[0352]
[0353]
[0354]
[0355]
[0356]
[0357]
[0358]
[0359]
[0360]
[0361]
[0362]
[0363]
[0364]
[0365]
[0366]
[0367]
[0368]
[0369]
[0370]
[0371]
[0372]
[0373]
[0374]
[0375]
[0376]
[0377]
[0378]
[0379]
[0380]
[0381]
[0382]
[0383]
[0384]
[0385]
[0386]
[0387]
[0388]
[0389]
[0390]
[0391]
[0392]
[0393]
[0394]
[0395]
[0396]
[0397]
[0398]
[0399]
[0400]
[0401]
[0402]
[0403]
[0404]
[0405]
[0406]
[0407]
[0408]
[0409]
[0410]
[0411]
[0412]
[0413]
[0414]
[0415]
[0416]
[0417]
[0418]
[0419]
[0420]
[0421]
[0422]
[0423]
[0424]
[0425]
[0426]
[0427]
[0428]
[0429]
[0430]
[0431]
[0432]
[0433]
[0434]
[0435]
[0436]
[0437]
[0438]
[0439]
[0440]
[0441]
[0442]
[0443]
[0444]
[0445]
[0446]
[0447]
[0448]
[0449]
[0450]
[0451]
[0452]
[0453]
[0454]
[0455]
[0456]
[0457]
[0458]
[0459]
[0460]
[0461]
[0462]
[0463]
[0464]
[0465]
[0466]
[0467]
[0468]
[0469]
[0470]
[0471]
[0472]
[0473]
[0474]
[0475]
[0476]
[0477]
[0478]
[0479]
[0480]
[0481]
[0482]
[0483]
[0484]
[0485]
[0486]
[0487]
[0488]
[0489]
[0490]
[0491]
[0492]
[0493]
[0494]
[0495]
[0496]
[0497]
[0498]
[0499]
[0500]
[0501]
[0502]
[0503]
[0504]
[0505]
[0506]
[0507]
[0508]
[0509]
[0510]
[0511]
[0512]
[0513]
[0514]
[0515]
[0516]
[0517]
[0518]
[0519]
[0520]
[0521]
[0522]
[0523]
[0524]
[0525]
[0526]
[0527]
[0528]
[0529]
[0530]
[0531]
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
<jloup@gailly.net>
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
<doc <DOT> cypher <AT> althacker <DOT> cjb <DOT> 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
<Mark.Daniel@wasd.vsm.com.au>
o 25 Sep 2002, initial draft
o 27 Sep 2002, added Bugtraq reference