Common Vulnerabilities and Exposures assigned an identifier CVE-2008-2276 to the following vulnerability: Cross-site request forgery (CSRF) vulnerability in Mantis 1.1.1 allows remote attackers to create new administrative users via user_create. Secunia advisory: http://secunia.com/advisories/30270 Upstream announcement of the fix in alpha version 1.2.0a1: http://sourceforge.net/project/shownotes.php?release_id=595025&group_id=14963 - 0008995: [security] CSRF Vulnerabilities in user_create (thraxisp). Upstream bug report: http://www.mantisbt.org/bugs/view.php?id=8995 Fix applied upstream: http://mantisbt.svn.sourceforge.net/viewvc/mantisbt?view=rev&revision=5132
Created attachment 305711 [details] Fix applied upstream svn diff -c 5132 https://mantisbt.svn.sourceforge.net/svnroot/mantisbt
Upstream patch only seems to add checks to make sure POST method is used. It seems the attacker should still be able to create a link that would do POST using JavaScript to achieve the very same results with little more complications. (This assumption is only based on reading the patch with no testing against mantis.)
Your assumptions are correct. I am working upstream and I was not satisfied as well of that solution; can you point me to commonly recognized best practices against this kind of attacks? I'm a bit confused because I see this as having a someone convince me doing rm -rf / is a good thing to do. If I trust him and happen to run it in a root shell, that does not make a vulnerability in bash (or anything else...) thanks in advance
This has been fixed in upstream version 1.1.x and 1.2.x via SVN commits 5287/5290 and 5288/5292 respectively.
(In reply to comment #3) > I'm a bit confused because I see this as having a someone convince me doing rm > -rf / is a good thing to do. If I trust him and happen to run it in a root > shell, that does not make a vulnerability in bash (or anything else...) Danger is they may be easier to obfuscate. If it's possible to perform actions via GET, something like img src=somescript.php?opts can perform attacker's actions without giving victim a way to realize something bad is happening. (In reply to comment #4) > This has been fixed in upstream version 1.1.x and 1.2.x via SVN commits > 5287/5290 and 5288/5292 respectively. Thanks! Direct link to commits in 1.1 branch: http://mantisbt.svn.sourceforge.net/viewvc/mantisbt?view=rev&revision=5287 http://mantisbt.svn.sourceforge.net/viewvc/mantisbt?view=rev&revision=5290 Reporters published their original advisory covering this CSRF issue along with two other issues: http://marc.info/?l=bugtraq&m=121130774617956&w=4 http://www.ush.it/team/ush/hack-mantis111/adv.txt
I'm working upstream for a solution on the other issues. How urgent is fixing the first issue should be treated? in other words, is it better to push a security update now and another when the other fix is ready or everything together (possibly within an official 1.1.2 release) ?
So far it seems all issues have low or moderate security impact, hence no urgent priority I believe. Do you know what is the expected release date for 1.1.2? Probably not worth doing backports if new upstream version is expected any time soon.
mantis-1.1.2-1.fc9 has been submitted as an update for Fedora 9
mantis-1.1.2-1.fc8 has been submitted as an update for Fedora 8
mantis-1.1.2-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
mantis-1.1.2-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
This issue was addressed in: Fedora: https://admin.fedoraproject.org/updates/F8/FEDORA-2008-6657 https://admin.fedoraproject.org/updates/F9/FEDORA-2008-6647