Moodle has released version 2.4.7 on November 11: https://moodle.org/mod/forum/discuss.php?d=243213 The issues fixed in this release will be listed in the release notes: http://docs.moodle.org/dev/Moodle_2.4.7_release_notes The bugs fixed are already there, but the security issues won't be listed there until next week, so an advisory won't be available until then. In the meantime, this could still be tested, as I've uploaded updated packages for Mageia 3 and Cauldron. No changes have been made other than updating to 2.4.7. For testing instructions, see: https://bugs.mageia.org/show_bug.cgi?id=10136#c3 Updated package in core/updates_testing: moodle-2.4.7-1.mga3 from moodle-2.4.7-1.mga3.src.rpm Reproducible: Steps to Reproduce:
Details and CVEs have been released: http://www.openwall.com/lists/oss-security/2013/11/25/1 Advisory: ======================== Updated moodle package fixes security vulnerabilities: Some files were being delivered with incorrect headers in Moodle before 2.4.7, meaning they could be cached downstream (CVE-2013-4522). Cross-site scripting in Moodle before 2.4.7 due to JavaScript in messages being executed on some pages (CVE-2013-4523). The file system repository in Moodle before 2.4.7 was allowing access to files beyond the Moodle file area (CVE-2013-4524). Cross-site scripting in Moodle before 2.4. due to JavaScript in question answers being executed on the Quiz Results page (CVE-2013-4525). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4522 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4523 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4524 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4525 https://moodle.org/mod/forum/discuss.php?d=244479 https://moodle.org/mod/forum/discuss.php?d=244480 https://moodle.org/mod/forum/discuss.php?d=244481 https://moodle.org/mod/forum/discuss.php?d=244482 http://docs.moodle.org/dev/Moodle_2.4.7_release_notes https://moodle.org/mod/forum/discuss.php?d=243213 ======================== Updated packages in core/updates_testing: ======================== moodle-2.4.7-1.mga3 from moodle-2.4.7-1.mga3.src.rpm
Severity: normal => major
Fedora has issued an advisory for this on November 15: https://lists.fedoraproject.org/pipermail/package-announce/2013-November/122391.html It lists two CVEs, which from what I understand, are both incorrect. My understanding is that CVE-2013-3630 was fixed in 2.4.6 and that CVE-2013-6780 only affects 2.3.x. LWN reference for those: http://lwn.net/Vulnerabilities/574925/
CC: (none) => davidwhodginsWhiteboard: (none) => advisory
Procedure: https://bugs.mageia.org/show_bug.cgi?id=10755#c2
Whiteboard: advisory => advisory has_procedure
There is a problem with the upgrade process. It displays the page with lots of green OK's for the various required bits, clicking continue fails with a reset connection. /var/log/httpd/error.log shows a segfault. # rpm -q php-suhosin package php-suhosin is not installed
http://localhost/moodle/admin/index.php?confirmupgrade=1&confirmrelease=1 This is the URL it is trying to load.
mga3 64 above btw. Adding feedback marker for now.
Whiteboard: advisory has_procedure => advisory has_procedure feedback
I can't reproduce on i586 (don't have 64 bit). If you start the httpd service back up again are you able to proceed and finish the upgrade? If you're able to reliably reproduce this problem BTW, we should file a bug against PHP.
Whiteboard: advisory has_procedure feedback => advisory has_procedure
I've experienced it twice x86_64, googling seems to suggest it could be php memory_limit too small for the db upgrade. # php -r "phpinfo();" | grep memory_limit memory_limit => 128M => 128M If that's the case it might be fixed with a custom php.ini in /var/www/moodle I'll try i586 to see if it's the same.
Well the memory limit is set specifically for Moodle already in /etc/httpd/conf/sites.d/moodle.conf. I guess things generally do take more memory on x86_64, so it could be that it does need to be increased. The 128MB was a recommendation from upstream documentation, but it could be outdated. If changing that to say 256MB fixes it, I'll certainly change it.
Seems OK i586, it didn't upgrade the db though, I was able to log in and the site was working straight away after with the update installed.
(In reply to claire robinson from comment #10) > Seems OK i586, it didn't upgrade the db though, I was able to log in and the > site was working straight away after with the update installed. That's odd. I did go through the upgrade when I tried it o_O
Once logged in x86_64 after installing the updated package.. Your Moodle files have been changed, and you are about to automatically upgrade your server to this version: 2.4.7 (Build: 20131111) (2012120307) Once you do this you can not go back again. Please note that this process can take a long time. Are you sure you want to upgrade this server to this version? This didn't happen i586.
Got further x86_64, using midori rather than firefox, not that that should make any difference. The step after the environment checks says the Box.net plugin is to be upgraded Box.net repository and Box.net portfolio. It says it is going to upgrade the database and actually completes. I'll have to try this again tomorrow, unless you can install a VM and debug it. None of these steps occurred with i586
Yeah I did run through this on a VM on Mageia 3 i586 and it did go through the upgrade procedure and worked fine.
Not here though. And it did segfault on x86_64. I'll try again tomorrow. Feedback marker or not, doesn't change the findings.
Well I don't see that any new issues have been introduced with this update, so other than increasing the memory limit if you find that that fixes the segfault problem, this update should be good to go.
Apart from the lack of database upgrade i586 and segfault which kills the installation, but I'll have to track those down myself apparently. I did mention these before in comment 8, 10, 12, 13 & 15. Trying again though to see if I can find the cause.
Testing in a VM with a snapshot so I could roll it back and easily repeat the update. It seems to do the database update the next time the main page is visited, ie. localhost/moodle rather than when browsing around. If a user is logged out prior to updating, the next login triggers the database upgrade. If logged in it doesn't seem to occur until the next visit to the home page. That's not a packaging issue though so I think i586 testing complete. Testing mga3 64 as soon as the upgrade has completed.
Whiteboard: advisory has_procedure => advisory has_procedure mga3-32-ok
Testing complete mga3 64 too. I can't reproduce the segfault now in an upgraded VM, there's something weird going on there. Completed the update twice without a hitch, both logged into moodle and with browser closed, so not sure what the issue is on my main unit. I'll need to investigate further but no time at present.
Whiteboard: advisory has_procedure mga3-32-ok => advisory has_procedure mga3-32-ok mga3-64-ok
Validating Could sysadmin please push from 3 core/updates_testing to updates Thanks!
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Update pushed: http://advisories.mageia.org/MGASA-2013-0356.html
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED
URL: (none) => http://lwn.net/Vulnerabilities/575367/