Discussions started by Tim Hunt

Moodle in English -> Security and privacy -> What is a security issue?

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

We have a policy in Moodle that, at the moment, all bug fixes go into 2.6 and 2.5 branches, and only security fixes go into Moodle 2.4. This means we need to know what is a security bug. At the moment, we seem to be implicit using the definition "a bug that an evil hacker could exploit", however, I am not sure that I agree.

I actually have a text-book definition of what IT security is, thanks to the OU course M886 Information Security Management.

Security is ensuring (as far as possible) the

    • confidentiality,
    • integrity and
    • availability

of information (that is important to your users).

The next stage in the analysis is to look a threats (things that might compromise one of those things) and vulnerabilities (the weaknesses in your system (and that is the whole system, software + hardware + users) that might be a way that one of the threats can actually damage confidentiality, integrity or availability.

OK, enough theory for now. Just note that a threat does not have to be some sort of evil hacker. It could be something like a power cut or hard disc failure, and the corresponding vulnerabilities would be not having a failover server, or a backup.

So anyway, the suggestion I want to make is that our current definition "bug someone could exploit" is not quite right. For example, issues like

  • An issue where some data is not written to the backup file correctly (e.g. MDL-44018), or
  • where some incorrect SQL can corrupt other data, as well as the DB update it is supposed to do (e.g. MDL-34451)

are security bugs, and should be fixed in 2.4 too.

 

This then leads to a second point. At the moment, another part of the security policy is that all security bugs get held for integration until just before the next stable release. This is where the issue of "bug someone could exploit" is important. If a bug is exploitable, then delaying integration is correct. If, however, the bug is a security issue, but not exploitable by a malicious hacker, then we should be integrating it as soon as possible.

 

So, in summary: we still need to track which bugs are exploitable, and handle the patches appropriately, but that does not mean that only exploitable bugs should have the fix back-ported to 2.4.

Average of ratings: -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Custom SQL report updated.

I just pushed a bunch of changes to https://github.com/moodleou/moodle-report_customsql.

I am goint to test it a bit more tomorrow, and then if all is well I am going to update the version in the plugins DB.

The main new feature in this release was done by Alan Carter of the OU. Reports are categories into categories, which helps keep the list organised if you have over 100 (which we do at the OU.)

There are a few other changes contibuted by various people in the community. (Thanks!) This new version should work with Moodle 2.6.

Average of ratings: Useful (2)