Bugzilla Bug 109667

Reported to Vendor-Sec by Steve Kemp from Debian:  
  
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

Created an attachment (id=70901) [details]
gnump3d-dot-dot.diff

Created an attachment (id=70902) [details]
gnump3d-xss.diff

luckyduck: please prepare a new ebuild with included patches and attach it to
this bug (do not commit it to Portage before 20051028).

Opening to other members of the sound herd, since luckyduck is quite MIA.

Could one of you please prepare a new ebuild with included patches and attach it
to this bug (do not commit it to Portage before 20051028).

I'm on it... please /msg me when it's ok to commit.

Created an attachment (id=71315) [details]
gnump3d-CAN-2005-3122.patch

for those interested in testing, the patch needed some cleanup.

Created an attachment (id=71316) [details]
gnump3d-CAN-2005-3123.patch

ditto...

Thx Jeremy. When ready, please attach everything needed to test (ebuild +
files)
so that we can call out arch testers on the bug.

Created an attachment (id=71443) [details]
gnump3d-2.9.4-r1.ebuild

Created an attachment (id=71444) [details]
gnump3d-2.9.5.ebuild

Dear arch security-liaisons, plz test the ebuild and report back (remember it's
still confidential ;)
Btw, could somebody check if my CC'ed liaisons are the up-to-date ones?

Checking.... and adding rangerpb for ppc64

the patch is unusable: with 2.9.4-r1, when i try to cd to a subdirectory called
'soul', the link points to http://soul/ instead of http://localhost:1234/soul.
2.9.4 works fine

Back to ebuild preperation as the attached one seems to fail.
If all else fails, there should be a new upstream release tomorrow.

Now public with the release of upstream 2.9.6.

Jeremy/sound team: maybe simpler to bump to that version if we're unsure of
those patches.

Cc cleanup to reduce pollution

2.9.6 in portage.  I've tested it to my satisfaction to put in portage, but I
don't have time at the moment to mark it stable for my archs.  I'll take care of
sparc, amd64, and x86 later tonight if someone else doesn't beat me to it.

Archs, please test and mark stable
Target KEYWORDS="alpha amd64 ~ppc ppc64 ~ppc-macos sparc x86"

alpha done

Cheers,
Ferdy

i'm still encountering the same problems as in comment 13

i think it is related to this (gnump3d.conf):

directory_format = <tr><td width="10%">&nbsp;</td><td><a
href="$LINK">$DIR_NAME</a></td><td>$SONG_COUNT</td><td>$DIR_COUNT</td><td>[$RECURSE]</td></tr>

i tried to comment it out, but then gnump3d would just crash right after firing up

i also changed href="$LINK" to href="abc $LINK", then the link are looking like
this:

http://localhost:1234/abc Soul/

from upstream changelog:

  2.9.7 [ 28th October 2005 ]
    - BUGFIX:  The previous release was broken.

indeed, after bumping the ebuild it worked fine. eradicator, could you commit it
with stable right away? kthxbye

Back to ebuild, we should definitely use 2.9.7 :)

*** Bug 110702 has been marked as a duplicate of this bug. ***

*** Bug 111122 has been marked as a duplicate of this bug. ***

Just catching up here a bit.  So are we waiting for a -2.9.7 ebuild to hit
portage so archs can test and mark stable?

Brent, yes that seems correct.  

*** Bug 111259 has been marked as a duplicate of this bug. ***

(In reply to comment #25)
> Just catching up here a bit.  So are we waiting for a -2.9.7 ebuild to hit
> portage so archs can test and mark stable?

on amd64 bumping the version number of the ebuild filename to 2.9.7 in my
portage overlay directory and updating to that version works perfectly.

eradicator/sound herd: please bump to 2.9.7, we're getting late on that one.

I've bumped it, but I haven't neither tried to compile it (I don't have the 
material time to start looking at configuring and testing it). 
Just wanted to make sure that this wouldn't remain unaddressed (and I'm tired 
of dupes :P) 

Thx Flameeyes,
Arches please test and mark 2.9.7 stable :
Target KEYWORDS="alpha amd64 ~ppc ~ppc-macos ppc64 sparc x86"

Marked ppc64 stable.

amd64 stable

x86 stable

sparc stable.

alpha stable

Apparently the amd64 keyword was not committed...

re-keyworded amd64

GLSA 200511-05