Hello Thorsten,
we received this via vendor-sec.

From: Steve Kemp <skx@debian.org>
Cc: vendor-sec@lst.de
User-Agent: Mutt/1.5.9i
Subject: [vendor-sec] GNUMP3d XSS + Directory traversal
Errors-To: vendor-sec-admin@lst.de
Date: Mon, 17 Oct 2005 21:40:27 +0100

[-- PGP Ausgabe folgt (aktuelle Zeit: Mi 19 Okt 2005 12:02:52 CEST) --]
gpg: Unterschrift vom Mo 17 Okt 2005 22:40:27 CEST, DSA SchlÃŒssel ID CD4C0D9D
gpg: Unterschrift kann nicht geprÃŒft werden: Ãffentlicher SchlÃŒssel nicht gefunden
[-- Ende der PGP-Ausgabe --]

[-- Die folgenden Daten sind signiert --]

[-- Anhang #1 --]
[-- Typ: text/plain, Kodierung: quoted-printable, GröÃe: 1,8K --]



  I'm aware of several distributions containing the
 GNUMP3d package, for serving MP3 files.

  In the interests of a coordinated release I'm suggesting
 a disclosure date of Friday 28th October which will coincide
 with a new upstream release.

  If that will cause problems let me know.



1. XSS Attacks [ CAN-2005-3122 ]
--------------------------------

  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/not-present/<script>..</script>

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

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



  Patch attached 'gnump3d-xss.diff'.



2. Directory Traversal [CAN-2005-3123]
--------------------------------------

  This is a far more serious flaw, which 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 "/../" only from the input paths.  And for Windows: (\..\).

  Patch attached, gnump3d-dot-dot.diff

  Apologies to all affected vendors.

Steve
--

[-- Anhang #2: gnump3d-dot-dot.diff --]
[-- Typ: text/plain, Kodierung: quoted-printable, GröÃe: 0,5K --]