General developer forum

 
 
Picture of sam marshall
Malware protection
Group DevelopersGroup Particularly helpful MoodlersGroup Testers

Hi,

We recently had a case where one course on our Moodle system was infected with malware. We fixed it before it went live to students but this is still a bit of a concern.

What seems to have happened is that a member of staff with editing permissions had an infected browser, and the particular malware involved was able to spot text areas (such as when the user was editing a Label) and insert its own script tags into the HTML just before it was submitted. After that, for everyone else who viewed the site, the malware would load and run.

In general, this shouldn't happen because everyone here is supposed to run antivirus software which should protect against this kind of thing. However, obviously there is a chance it could slip through the net.

In order to fix it Derek and I had to go through searching database tables and replacing everything blah blah. It was pretty tedious.

I'm wondering if Moodle should have general protection against this kind of malware (in other words, against the case where teachers who are editing websites can end up inserting malware scripts without their knowledge).

My thinking is:

  • Malware usually requires the insertion of a script tag or a remote (not locally hosted via PLUGINFILE) .swf or something. (There might be some other attack mechanisms, this is just off the top of my head...)
  • In 99.9% of cases, when a user edits something that has an html field, even if it's one of the fields that permits these things (such as a label) they do not want to insert any of them this time.
  • What if Moodle could have an extra confirmation whenever you save any form (or at least most forms) that includes a <script> tag or non-local swf in its data? In other words, you save the form, it initially fails validation with a big 'are you sure' type box at the top with a checkbox that you have to click to approve that you really mean to add the script tag. The box could display the code for the script tag (or whatever) that you're adding, so you can see if it's something you meant to add or not.
  • If you did tick the confirmation and save the form again, it would work (so you can still add script tags if you need to); a special log entry could be added to record this.

This would not prevent malware designed specifically to attack this version of Moodle (as it could automatically click the box and whatever else) - it is impossible to prevent that. However, it should prevent teachers from adding generic malware to a site. As an added benefit, it might inform users - including students as well as teachers, if this runs on all forms, even though any script tags the students put in won't harm Moodle as they will already be filtered out - if they have a malware problem.

I'm not sure whether this is (a) feasible, or (b) the best approach - maybe there is a better way to achieve it. Alternatively, this has only happened to us once, so maybe it's not even a problem we should worry about as it won't happen again. I thought it was at least worth considering though.

Any opinions?

--sam

 
Average of ratings:Useful (1)
Picture of Howard Miller
Re: Malware protection
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers

Perhaps I'm being naive, but I thought that script stuff and the like was filtered out when stuff was submitted to Moodle? One often reads forum posts along the lines of "How do I run javascript in my Page resources?". Answer, you can't.

 
Average of ratings: -
Tim at Lone Pine Koala Sanctuary
Re: Malware protection
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers

Teachers are allowed to insert <javascript> and other dangerous stuff when they are editing teacher-only places like labels and quiz questions.

This is, of course, a security compromise, but a necessary one, becuase there are some valid editcational things that you can do if you can paste a script into these places.

 
Average of ratings:Useful (1)
Picture of Howard Miller
Re: Malware protection
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers

Yike. Can this be disabled? My inclination is that I'd much rather they didn't wink

 
Average of ratings: -
Dan at desk in Moodle HQ, Perth
Re: Malware protection
 
Average of ratings:Useful (3)
Picture of sam marshall
Re: Malware protection
Group DevelopersGroup Particularly helpful MoodlersGroup Testers

Tim's already answered this but just to explain one detail about how it works which may be disturbing if you look in your database and don't realise: Moodle actually doesn't filter anything on input, so e.g. students can put JavaScript into forum messages and you might see this in your database. However, it will be removed on output. (The intention of this is that if the filtering needs to be updated, it will still work on old data.)

By the way, Rod has suggested an alternative to my idea which is an administrator-set whitelist of permissible script locations/patterns. (E.g. if a teacher wants to use whatever script from Facebook or YouTube say, they have to first get an administrator to add it to the whitelist, and then they will be allowed to put it into a Page or Label or wherever.) I think if this were added it would have to be an option, so as not to break existing behaviour - and it might also be desirable to run this part on output rather than on input (same reason as above) although that will mean there's no opportunity to actually explain why it doesn't work to the user, so the UI will suck a bit. Another challenge with this approach would be inline script - we probably want to allow some inline script sometimes, but how do you get around malware that is written inline...

Note that neither approach prevents teachers from writing evil javascript if they actually want to: they would just need to put it into an html file in a File object.

--sam

 
Average of ratings:Useful (1)
Picture of Joseph Rézeau
Re: Malware protection
Group DevelopersGroup Particularly helpful MoodlersGroup TestersGroup Translators

sam "... Note that neither approach prevents teachers from writing evil javascript if they actually want to: they would just need to put it into an html file in a File object."

Great! evil

 
Average of ratings: -