The release announcement and ChangeLog both reference a security issue fixed: https://forge.indepnet.net/projects/glpi/versions/771 So it appears to be the XSS issues in this bug (with links to revisions to fix): https://forge.indepnet.net/issues/3705 Not 100% how many older versions are affected or if CVEs have been requested.
CC: (none) => guillomovitch
OK, apparently the two "CSRF prevention" bugs are security issues also: https://forge.indepnet.net/issues/3704 https://forge.indepnet.net/issues/3707 CVEs have been assigned: http://seclists.org/oss-sec/2012/q3/73 Bug 3705 is CVE-2012-4003. Bugs 3704 and 3707 are CVE-2012-4002.
Summary: glpi new security issue fixed in 0.83.3 => glpi new security issue fixed in 0.83.3 (CVE-2012-4002 and CVE-2012-4003)
Fedora has released an update for this (as well as glpi-data-injection, glpi-mass-ocs-import, and glpi-pdf). http://lists.fedoraproject.org/pipermail/package-announce/2012-August/084643.html http://lists.fedoraproject.org/pipermail/package-announce/2012-August/084644.html http://lists.fedoraproject.org/pipermail/package-announce/2012-August/084645.html http://lists.fedoraproject.org/pipermail/package-announce/2012-August/084646.html from http://lwn.net/Vulnerabilities/509945/
Assignee: bugsquad => guillomovitch
I've updated GLPI earlier from 0.80.7 to 0.83.4 this week, as well as all distributed plugins. I can't find any information about the exact version affected, but as everything relates to 0.83 only, I'd presume we were actually not vulnerable.
Status: NEW => RESOLVEDResolution: (none) => FIXED
This is only fixed in Cauldron.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)Whiteboard: (none) => MGA2TOO, MGA1TOO
If you're sure only 0.83 is affected, we can close this again.
After enquiring with upstream, 0.80 is affected, but unsupported, meaning no available patches... I had a look at the changes involved to evaluate the work need to port the fixes myself. The fixes for XSS vulnerability (2012-4003) are quite localized, but the ones for the XSRF vulnerability (2012-4002) are far more invasive. I just submitted a 0.80.7-2.1.mga2 package in updates_testing, fixing the first issue. Unless someone else volonteers to also fix the second issue, it seems that is the maximum achievable here.
(In reply to comment #6) > After enquiring with upstream, 0.80 is affected, but unsupported, meaning no > available patches... Nice. Do we know if 0.78 (Mageia 1) is affected? > I had a look at the changes involved to evaluate the work need to port the > fixes myself. The fixes for XSS vulnerability (2012-4003) are quite localized, > but the ones for the XSRF vulnerability (2012-4002) are far more invasive. I > just submitted a 0.80.7-2.1.mga2 package in updates_testing, fixing the first > issue. Thanks. > Unless someone else volonteers to also fix the second issue, it seems > that is the maximum achievable here. As far as I know, you're the only developer we have that's interested in this package. Maybe another distro will backport a fix at some point. So, the plugin updates Fedora issued were for compatibility with the CSRF fix, so if we're not fixing that, we don't have to worry about those at this time.
Mandriva has issued an advisory for this (for MES5) today: http://www.mandriva.com/en/support/security/advisories/?dis=mes5&name=MDVSA-2012:132 They decided to just update to the newest versions.
GLPI 0.78 is probably affected as well. I just submitted glpi-0.78.2-2.3.mga1 with a backported patch to updates_testing. What did mandriva is a bit dangereous: first, they ship major version as security update, forcing database schema upgrade, second, they ship incompatible plugin versions, such as fusioninventory plugin...
Depends on: (none) => 7126
Thanks Guillaume. I have opened Bug 7126 to get this XSS fix to QA. I'll leave this bug open just in case someone backports a fix for the CSRF issues.
Version: Cauldron => 2Whiteboard: MGA2TOO, MGA1TOO => MGA1TOO
CC: (none) => oe
MGA1 isn't supported anymore, right ? So I'm closing this bug.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
This bug is for Mageia 2. Mageia 1 removed from whiteboard due to EOL.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)Whiteboard: MGA1TOO => (none)
Bugs 7126 and 7157 have been closed, I'm closing this ticket.
As I said in Comment 10, we have not fixed the CSRF issues (CVE-2012-4002) for Mageia 2, which is why this is still open.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Indeed. However, there is no patch available for 0.80, and the 0.83 ones are far too much invasives to be ported: https://forge.indepnet.net/issues/3704 https://forge.indepnet.net/issues/3707 I'd rather close this ticket now as WONTFIX than waiting for mga2 end of life to close it.
Then maybe we should update this to 0.83.7 backported from Cauldron. We have 0.80 here, which for quite some time now has been unsupported upstream, and we still are supposed to be supporting Mageia 2 for like 10 more months. Fedora and Mandriva both updated to 0.83.4 to fix these issues.
That's also an option. However, a version update means a database schema changes, and breaks all installed plugins, which is a bit harsh change for something installed and running. I don't think this is very wise here.
I can certainly understand that perspective. There's arguments to be made for both sides. Arguments to update: - We continue to provide support for this package. - We move to a version that's supported upstream. - We only have to support one version of the software, as it's the same in Mageia 2 and Mageia 3. - We fix a security hole. - People will have to upgrade this when they upgrade to Mageia 3 anyway, dealing with it now will actually make that transition later less painless. Obviously careful admins will deal with this update carefully. - Everyone else is doing it :o) Arguments to not update: - Lot of packager work initially to prepare the update and update the plugins too. - More invasive/involved update for the users. Both are reasonable arguments. Ultimately, it's your package and you know more about it than anyone in Mageia, so I'll trust your decision.
Not updating the software version doesn't mean dropping support completly, it just means than some issues with a defavorable complexity/severity ratio won't be backported. Which is is own analysis of the present issue. And I really think we should avoid introducing any disturbing changes in updates. I'm personnaly really biased toward allowing users to automatically apply those updates in non-supervised manner, which means typically vetoing any change involving a manual intervention to keep something running.
(In reply to Guillaume Rousse from comment #19) > I'm personnaly really biased toward allowing users to automatically > apply those updates in non-supervised manner, which means typically vetoing > any change involving a manual intervention to keep something running. In general I agree with that. In fact, since Mageia 2, I have all my servers installing updates daily with a cron job since it's worked so well. Unfortunately every once in a while to fix some security issues there may be some manual intervention needed, which we always explain in the advisories.
I won't provide security fixes for those old versions.
Status: REOPENED => RESOLVEDResolution: (none) => WONTFIX
Just leaving a note on this bug that additional issues also affect the Mageia 2 GLPI package that will not be fixed. They are described in Bug 10579.
Depends on: (none) => 10579