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 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:
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 attachment 70901 [details, diff]
Created attachment 70902 [details, 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 attachment 71315 [details, diff]
for those interested in testing, the patch needed some cleanup.
Created attachment 71316 [details, diff]
Thx Jeremy. When ready, please attach everything needed to test (ebuild + files)
so that we can call out arch testers on the bug.
Created attachment 71443 [details]
Created attachment 71444 [details]
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
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"
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%"> </td><td><a
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
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)
Arches please test and mark 2.9.7 stable :
Target KEYWORDS="alpha amd64 ~ppc ~ppc-macos ppc64 sparc x86"
Marked ppc64 stable.
Apparently the amd64 keyword was not committed...