[RLSA_02-2006] OSU httpd for OpenVMS path and directory disclosure - is this a bug or a feature?

Type securityvulns
Reporter Securityvulns
Modified 2006-09-20T00:00:00


     *** 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.

  1. 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:

File /staff$disk/www_server/home/NONEXISTANT &#40;/NONEXISTANT&#41; 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 &#40;VMS &#39;*&#39; char&#41; on URL specifications as in:


Which leads to the content of the first directory starting with the letter &#39;a&#39; 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 &#40;not brazilian kiddies, of course&#41; could create a very simple script to perform brute-force attack to guess directory names and access them directly.
  1. Solution

    Nothing yet.

  2. 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