unsticky has discovered a vulnerability in DokuWiki, which can be exploited by malicious people to bypass certain restrictions. Input passed to the "media" parameter in lib/exe/fetch.php is not properly sanitised before being used. This can be exploited to bypass certain restrictions via CRLF character sequences and inject arbitrary HTTP headers and HTTP body data in a request. Successful exploitation e.g. makes it possible to conduct cross-site scripting attacks. The vulnerability is confirmed in version 2006-03-09e. Other versions may also be affected. Reproducible: Didn't try
Noticed this XSS too... http://www.securiteam.com/unixfocus/5YP0N1FKAE.html
ping web-apps
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-6965
*** Bug 150950 has been marked as a duplicate of this bug. ***
This bug has been fixed as of 2006-10-17, see DokuWiki bugtracker [1] for further details. [1] http://bugs.splitbrain.org/?do=details&id=935
new ebuild needed for latest version
Hi, new version still out of portage? Why?? http://bugs.gentoo.org/show_bug.cgi?id=150950 dokuwiki-20061106.ebuild > http://bugs.gentoo.org/attachment.cgi?id=103294 "Changes: removed the last MY_PV argument, because this release doesn't have an alphabetic character at the end of PV" Wokrs fine for my amd64, please test and report...
*** Bug 169833 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > *** Bug 169833 has been marked as a duplicate of this bug. *** > I think that Bug 169833 shows one more thing: old dokuwiki version gives problems with new php. So the new ebuild has to go soon in portage.
Created attachment 112712 [details] Elias Probst's ebuild from bug #150950. Elias Probst originally submitted this ebuild under bug #150950. Could someone please get it into the portage tree? It's been there, waiting for someone to get it in since the beginning of December.
ping web-apps: if you don't have time to maintain this package, then please put it in p.mask so that it will not be concerned by the security process anymore
(In reply to comment #11) > ping web-apps: if you don't have time to maintain this package, then please put > it in p.mask so that it will not be concerned by the security process anymore > Please feel free to p.mask it - ramereth seems to be MIA
Security team, your opinion? Probably i will email -dev. security vulnerabilities: CVE-2006-6965 CVE-2006-5099 CVE-2006-5098 CVE-2006-4679 CVE-2006-4675 CVE-2006-4674 CVE-2006-2945 CVE-2006-2878
I've seen this in quite a few places in active use, I'd vote yes for a GLSA.
I think you should mail -dev with maintainer wanted.
-dev'ed let's wait for a few days before masking it
I am using dokuwiki - although only lightly - and like it. Therefore I'll volunteer to take on its maintainership, because I really don't want it to go. 20061106 committed in the tree. If someone is against it, or wishes to maintain dokuwiki more than me, just contact me.
Nice, thanks a lot Andrej. Hi x86, please test and mark stable dokuwiki-20061106, thanks!
x86 done
(In reply to comment #13) > Security team, your opinion? Probably i will email -dev. > > security vulnerabilities: > 2006-03-09e affected by: > CVE-2006-6965 not affected by: > CVE-2006-5099 > CVE-2006-5098 > CVE-2006-4679 > CVE-2006-4675 > CVE-2006-4674 > CVE-2006-2945 > CVE-2006-2878 security please vote
(In reply to comment #20) > (In reply to comment #13) > > Security team, your opinion? Probably i will email -dev. > > > > security vulnerabilities: > > > > 2006-03-09e affected by: > > > CVE-2006-6965 Um, this is about 2006-11-06, not about 2006-03-09e (which I have already removed from the tree anyway, as 2006-11-06 has equal keywords).
(In reply to comment #20) > (In reply to comment #13) > > security please vote > tending to vote yes, as it seems to be widely used.
(In reply to comment #21) > > Um, this is about 2006-11-06, not about 2006-03-09e (which I have already > removed from the tree anyway, as 2006-11-06 has equal keywords). > Yep, I just wanted to make clear that we are only talking about one issue (CVE) and not the whole list, since we dealt with those in earlier GLSAs already ;-) I also tend to vote yes btw.
I tend to vote YES.
i would vote "no" for the very weak impact, on a web-app that is typically prone to XSS issues.
i'm filing a GLSA request due to your "yes" votes
GLSA 200704-08 thanks everyone