Bug 11671 - moodle new security issues fixed in 2.4.7
Summary: moodle new security issues fixed in 2.4.7
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 3
Hardware: i586 Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/575367/
Whiteboard: advisory has_procedure mga3-32-ok mga...
Keywords: validated_update
Depends on:
Reported: 2013-11-14 22:13 CET by David Walser
Modified: 2013-12-02 16:45 CET (History)
3 users (show)

See Also:
Source RPM: moodle-2.4.6-1.mga3.src.rpm
Status comment:


Description David Walser 2013-11-14 22:13:37 CET
Moodle has released version 2.4.7 on November 11:

The issues fixed in this release will be listed in the 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:

Updated package in core/updates_testing:

from moodle-2.4.7-1.mga3.src.rpm


Steps to Reproduce:
Comment 1 David Walser 2013-11-25 14:23:16 CET
Details and CVEs have been released:


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).


Updated packages in core/updates_testing:

from moodle-2.4.7-1.mga3.src.rpm

Severity: normal => major

Comment 2 David Walser 2013-11-25 19:22:04 CET
Fedora has issued an advisory for this on November 15:

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:
Dave Hodgins 2013-11-26 20:30:18 CET

CC: (none) => davidwhodgins
Whiteboard: (none) => advisory

Comment 3 claire robinson 2013-11-27 14:21:43 CET
Procedure: https://bugs.mageia.org/show_bug.cgi?id=10755#c2

Whiteboard: advisory => advisory has_procedure

Comment 4 claire robinson 2013-11-27 15:23:07 CET
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
Comment 5 claire robinson 2013-11-27 15:23:42 CET

This is the URL it is trying to load.
Comment 6 claire robinson 2013-11-27 15:27:16 CET
mga3 64 above btw. Adding feedback marker for now.

Whiteboard: advisory has_procedure => advisory has_procedure feedback

Comment 7 David Walser 2013-11-27 15:58:49 CET
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

Comment 8 claire robinson 2013-11-27 18:03:09 CET
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.
Comment 9 David Walser 2013-11-27 18:05:37 CET
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.
Comment 10 claire robinson 2013-11-27 18:18:05 CET
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.
Comment 11 David Walser 2013-11-27 18:24:21 CET
(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
Comment 12 claire robinson 2013-11-27 18:42:58 CET
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.
Comment 13 claire robinson 2013-11-27 18:48:26 CET
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
claire robinson 2013-11-27 18:50:54 CET

Whiteboard: advisory has_procedure => advisory has_procedure feedback

Comment 14 David Walser 2013-11-27 19:10:30 CET
Yeah I did run through this on a VM on Mageia 3 i586 and it did go through the upgrade procedure and worked fine.

Whiteboard: advisory has_procedure feedback => advisory has_procedure

Comment 15 claire robinson 2013-11-27 20:12:53 CET
Not here though. And it did segfault on x86_64. I'll try again tomorrow.

Feedback marker or not, doesn't change the findings.
Comment 16 David Walser 2013-11-27 20:17:31 CET
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.
Comment 17 claire robinson 2013-11-28 07:53:01 CET
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.
Comment 18 claire robinson 2013-11-28 09:59:58 CET
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

Comment 19 claire robinson 2013-11-28 13:38:55 CET
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.
claire robinson 2013-11-28 13:39:09 CET

Whiteboard: advisory has_procedure mga3-32-ok => advisory has_procedure mga3-32-ok mga3-64-ok

Comment 20 claire robinson 2013-11-28 13:41:39 CET

Could sysadmin please push from 3 core/updates_testing to updates


Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Comment 21 Thomas Backlund 2013-11-30 22:45:05 CET
Update pushed:

CC: (none) => tmb
Resolution: (none) => FIXED

David Walser 2013-12-02 16:45:45 CET

URL: (none) => http://lwn.net/Vulnerabilities/575367/

Note You need to log in before you can comment on or make changes to this bug.