Multiple cross-site request forgery (CSRF) vulnerabilities in Joomla! before 1.5 RC4 allow remote attackers to (1) add a Super Admin, (2) upload an extension containing arbitrary PHP code, and (3) modify the configuration as administrators via unspecified vectors. Reproducible: Always
maintainers - please advise
We don't have the 1.5-release series in Portage yet. There are only release candidates available. I'd suggest to wait for 1.0.14. A release candidate for this version has been made available recently.
Thx Gunnar. Given that impact is pretty serious it would be best if we don't wait too long though.
*** Bug 207043 has been marked as a duplicate of this bug. ***
1.5.0 final is out... http://www.joomla.org/content/view/4488/1/
added joomla-1.5.0. unstable on all archs. removed insecure 1.0.13. webapps done.
There is a 1.0.14 on the way (RC status at the moment). 1.5 is really completely rewritten and I won't migrate my current web page to it, so maybe waiting for another 1.0.x release is the way to go, as Gunnar already suggested. The security breaches are known since December anyway...
http://www.joomla.org/component/option,com_jd-wp/Itemid,105/p,486/ <snip> After releasing Joomla! 1.5 stable we have discovered a high priority security issue. The vulnerability has been discovered in XML-RPC in combination with the blogger API. There is a security problem in this code that makes it possible to alter the articles on your site (including removal). This problems has been fixed currently by members of the development team and the Joomla! bug squad, solution is now available from Subversion. So what do you need to do until we release Joomla! 1.5.1? All Joomla! users who have enabled the XML-RPC Blogger API plugin should disable it! If you have never enabled this plugin you do not need to do anything. </snip> Wonderful, plop!
Joomla is ~arch only.
1.0.14 is released now, maybe this option should still be offered.
Joomla 1.5.1 is also released. I think it's fix the bug with the XML-RPC.
(In reply to comment #11) > Joomla 1.5.1 is also released. I think it's fix the bug with the XML-RPC. > According to this: http://www.joomla.org/content/view/4560/1/ This bug fixed on Joomla 1.5.1 version.
*** Bug 210672 has been marked as a duplicate of this bug. ***
1.5.1 in cvs ... looking at the CVE history for joomla, i'd suggest to handle it like we do already with wordpress, hard-mask and scream that this crap is in no way security supported ..
(In reply to comment #14) > 1.5.1 in cvs ... looking at the CVE history for joomla, i'd suggest to handle > it like we do already with wordpress, hard-mask and scream that this crap is in > no way security supported .. +1 on this...
masked
Why did you remove joomla 1.0.x? I assume that this version have less bugs than 1.5.x version.
i've readded the 1.0 branch wrt comment #7 and #17 .. this won't affect the security mask though
(In reply to comment #14) > 1.5.1 in cvs ... looking at the CVE history for joomla, i'd suggest to handle > it like we do already with wordpress, hard-mask and scream that this crap is in > no way security supported .. > I don't understand the hard mask. If there are security flaws they should be reported upstream just like any other package. This logic says we should hard mask everything until enough decades have passed to obsolete the package enough that security is no longer an issue as nobody uses it any longer... I realize nothing stops me from downloading the tarball from joomla.org and installing it, but this defeats the purpose of using Gentoo. I can also unmask it and emerge it, but you are putting up a large barrier for many users by hard masking it; why do we even have ~x86 anymore if everything is constantly getting hard masked?
(In reply to comment #19) The statement we are making by hard masking the package is that we cannot support the package security-wise, but that we expect this to be temporary (otherwise it would be simply removed). The difference this has to ~arch packages is that those *are* security supported, and we will track every single vulnerability that we come across and that will torture our maintainers. I would expect the mask to be removed once Joomla's security track improves, I'm not sure if the 1.5 version brought news there.
(In reply to comment #20) > (In reply to comment #19) > The statement we are making by hard masking the package is that we cannot > support the package security-wise, but that we expect this to be temporary > (otherwise it would be simply removed). The difference this has to ~arch > packages is that those *are* security supported, and we will track every single > vulnerability that we come across and that will torture our maintainers. > > I would expect the mask to be removed once Joomla's security track improves, > I'm not sure if the 1.5 version brought news there. > Thank you for the clarification :)
(In reply to comment #20) > I would expect the mask to be removed once Joomla's security track improves, > I'm not sure if the 1.5 version brought news there. well, 1.5 is still young, but has not seen a security vulnerability yet, afaics. we could change the mask to =joomla-1.0* only
Could you please bump the ebuild to 1.5.2? Thanks.
(In reply to comment #23) > Could you please bump the ebuild to 1.5.2? Thanks. Please make it 1.5.3 instead...
1.5.3 in cvs
(In reply to comment #20) > I would expect the mask to be removed once Joomla's security track improves, > I'm not sure if the 1.5 version brought news there. > From Secunia website: " Unpatched 0% (0 of 18 Secunia advisories) Most Critical Unpatched There are no unpatched Secunia advisories affecting this product, when all vendor patches are applied.. " which appears to refer to 1.5.7
@bill: If joomla would simply leave any sec issue open it would be removed from the tree immediately. It is currently hard masked as the frequency of discovered security issues is too high for us to maintain it security wise.
https://bugs.gentoo.org/253483
This is a very old bug and everyone knows joomla often has security bugs. Closing noglsa.
Olivier Huber offered to take over maintenance. As his proxy I hereby think that we should reconsider the security masking, if the maintenance proves to be reliable. Security, are you ok with it?
(In reply to comment #30) > Olivier Huber offered to take over maintenance. As his proxy I hereby think > that we should reconsider the security masking, if the maintenance proves to be > reliable. Security, are you ok with it? Well, the masking of joomla had nothing to do with not being able to commit version bumped ebuilds. But joomla, like the other apps in bug 211166 have a long history of security vulnerabilities and there is no improvement in sight. These applications shouldn't be used at all actually, but that's how life works with PHP apps ;)
(In reply to comment #31) > (In reply to comment #30) > > Olivier Huber offered to take over maintenance. As his proxy I hereby think > > that we should reconsider the security masking, if the maintenance proves to be > > reliable. Security, are you ok with it? > > Well, the masking of joomla had nothing to do with not being able to commit > version bumped ebuilds. But joomla, like the other apps in bug 211166 have a > long history of security vulnerabilities and there is no improvement in sight. > These applications shouldn't be used at all actually, but that's how life works > with PHP apps ;) Horde is impacted regularly, too (and PHP-based). There was a problem with regular bumping as web-apps is badly understaffed...you know that well. :) Anyway, we can start with a small step and introduce it into testing. Joomla's history of security problems is well-known but new ones seem to arise in a two to three months interval now.
(In reply to comment #32) > Horde is impacted regularly, too (and PHP-based). There was a problem with > regular bumping as web-apps is badly understaffed...you know that well. :) > Anyway, we can start with a small step and introduce it into testing. Joomla's > history of security problems is well-known but new ones seem to arise in a two > to three months interval now. Yeah, you probably shouldn't use horde as well ;) Anyway, i'm not against adding joomla again, i was just saying that there was more reason than simply not being able to commit a new ebuild ...
security, any word from you?
(In reply to comment #34) > security, any word from you? So it is unmasked again.
I thought I replied. :o Summing up what I typed already but somehow didn't send: * Make sure that the version in the tree is not vulnerable to any known issues * Remove all vulnerable ebuilds * Try to have a good response time for the next bump. * Contact us beforehand if you want to stabilize the package. And for the record: Horde's issues are not quite as grave as the things found in Joomla and I've been taking care of Horde for a time now, so we're fine there.
(In reply to comment #36) > * Make sure that the version in the tree is not vulnerable to any known issues Done. > * Remove all vulnerable ebuilds Done now. > * Try to have a good response time for the next bump. Olivier will assist me, I use it on my webspace (not Gentoo) and thus read the Joomla! security RSS. This will hopefully help. > * Contact us beforehand if you want to stabilize the package. Of course. > And for the record: Horde's issues are not quite as grave as the things found > in Joomla and I've been taking care of Horde for a time now, so we're fine > there. It was just an example. :)
