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 attachment 70901 [details, diff] gnump3d-dot-dot.diff
Created attachment 70902 [details, diff] 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 attachment 71315 [details, diff] gnump3d-CAN-2005-3122.patch for those interested in testing, the patch needed some cleanup.
Created attachment 71316 [details, diff] 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 attachment 71443 [details] gnump3d-2.9.4-r1.ebuild
Created attachment 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%"> </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