[RLSA_02-2006] OSU httpd for OpenVMS path and directory disclosure - is this a bug or a feature?
*** rfdslabs security advisory ***
Title: OSU httpd for OpenVMS path and directory disclosure - is this a bug or a
feature? [RLSA_02-2006]
Versions: OSU/3.11alhpa, OSU/3.10a (probably others)
Vendor: David Jones, Ohio State University
(http://www.ecr6.ohio-state.edu/www/doc/serverinfo.html)
Date: 18 May 2006
Authors: Julio Cesar Fort <julio *NO_SPAM* rfdslabs com br>
Iruata Souza, the VMS freak <iru.muzgo *NO_SPAM* gmail com>
September 18th: HAPPY BIRTHDAY, MUZGO! :D
1. Introduction
OSU is a http server for Compaq/HP (rest in peace, DEC) OpenVMS operating
system. It supports a wide variety of TCP stacks for VMS like UCX, MultiNet,
among others. Besides this OSU supports CGI (written in DCL), SSI and many
others.
2. Details
2.1 - Path disclosure (tested on OSU 3.11)
This one is pretty simple. If one requests a non-existant file to the
server it simply returns like this:
Error:
File /staff$disk/www_server/home/NONEXISTANT (/NONEXISTANT) could not be
opened VMS especification:
staff$disk:[www_server.home]NONEXISTANT index.url present
Exposing path information that, in our opinion, should not be exposed.
2.2 - Directory and file disclosure
This occurs by the faulty handling of wildcards (VMS '*' char) on URL
specifications as in:
http://muzgo.is.a.freak.foo.bar/a*/
Which leads to the content of the first directory starting with the letter
'a' being shown
and totally browsable. Sometimes there might be hidden or useful information:
----------------------------
| Files |
| |
| ACRAPPY.DOC{stat error} |
| APROGRAM.EXE{stat error} |
| AN.OBJ{stat error} |
| PR0N.XXX{stat error} |
----------------------------
Just a single click and you can view the content or download the exposed
files. A smart attacker (not brazilian kiddies, of course) could create a very
simple script to perform brute-force attack to guess directory names and access
them directly.
3. Solution
Nothing yet.
4. Timeline
Apr 2006: Vulnerability detected;
18 May 2006: Advisory written;
09 Jun 2006: Vendor contacted;
09 Jul 2006: No response from vendor;
18 Sep 2006: Advisory released.
Thanks to barrossecurity.com, gotfault.net brothers, risesecurity.org, Lucien
Rocha, Victor Galante, and friends everywhere.
Iruata Souza also would like to thank Diego Casati.
www.rfdslabs.com.br - computers, sex, human mind, music and more.
Recife, PE, Brazil