Bug 130963 (CVE-2005-3123)

We received the following report via vendor-sec.
This issue is *not public* yet, please keep any information about it inside SUSE.

   6 remote non-root user
  -1 extra package
  -1 default inactive

Total Score: 4 (Moderate)

Date: Thu, 27 Oct 2005 10:28:11 +0200
From: Martin Schulze <joey@infodrom.org>
To: Free Software Distribution Vendors <vendor-sec@lst.de>
Subject: [vendor-sec] CVE-2005-3122 CVE-2005-3123: GNUMP3d security problems - XSS + directory traversal.

Steve Kemp discovered two vulnerabilities in gnump3d, a streaming
server for MP3 and OGG files.  The Common Vulnerabilities and
Exposures Project identifies the following problems:

CVE-2005-3122

    The 404 error page does not strip malicious javascript content
    from the resulting page, which would be executed in the victims
    browser.

CVE-2005-3123

    By using specially crafting URLs it is possible to read arbitary
    files to which the user of the streaming server has access to.

    Stripping all "../" from the path should be sufficient as well.

This one is not yet public, so we can coordinate if you prefer it.


Patches attached.

----- Forwarded message from Steve Kemp <skx@debian.org> -----


1. XSS Attacks
--------------

  There are two XSS attack vectors in the handling of files.

  When files are not found the requested URI isn't stripped from
 the 404 page, allowing javascript execution via:

	http://host:port/ssssssssss/<script>..</script>

  The second flaw comes from a similar refusal to serve any request ending
 in the string '.password'.  This is an identical vulnerability as the
 request is internally converted into a 404 response regardless of
 whether the file exists or not:

	http://host:port/any/path/<script>...</script>/.password


  Patch attacked 'gnump3d-xss.diff'.



2. Directory Traversal
----------------------

  This is a far more serious flaw, it allows the reading of
 arbitary files which the user the server is running as has access to.
 (gnump3d - by default).

  The flaw comes from the attempt to sanitize input paths, ironically
 to prevent these very attacks.

  The process looks like this:

	Strip ".." from all inputted paths.
	Then strip "//" from all inputted paths.

  This allows the following conversion to happen:

	/.//./
        /../
  
  So with the root set to /home/mp3 the following allows the password
 file to be retrieved:

GET /.//.///.//./etc/passwd HTTP/1.0

  The solution chosen is to :

	1.  Strip ".." from the paths as before.
	2.  But convert "//" to "/" (multiple times if necessary).

  I think that is sufficient, but if I'm mistaken I'd love to be
 educated. 
 
  Patch attached, gnump3d-dot-dot.diff

Steve
--

----- End forwarded message -----

Regards,

	Joey

-- 
A mathematician is a machine for converting coffee into theorems.   Paul Erdös