XMLRPC with Firefox 17.0 not possible

Current theory is that it's the fix for the following described security bug: http://blog.mozilla.org/security/2012/10/10/security-vulnerability-in-firefox-16/

Hi Werner,

I've spent a fair bit of time debugging this now and it appears to be entirely on the moodle side of things.

The useragent for Firefox 17 altered the display of the Gecko version, so the useragent now reads:
"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0"

Instead of:
"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0"

http://tracker.moodle.org/browse/MDL-35469 is a resolved bug in moodle that was supposed to track the appropriate changes.

However, for some reason, my (and your) Firefox 17 user agent is stuck reporting to Moodle with the old format despite reporting elsewhere (eg, to mahara) correctly with the new format. This is possibly by some user-agent caching somewhere, but I cannot find how to un-cache it; even emptying the cache directory in the moodle data directory makes no difference.

When a mnet session is started, the user agent of the browser is passed in a hashed form, but because moodle is seeing a different agent hash than mahara is, their browser hashes don't match.

I've opened http://tracker.moodle.org/browse/MDL-36838 to get the perspective of the Moodle developers.

The user agent string sent by Firefox 17 is different in Moodle and Mahara.

Mozilla developers changed the user agent string in Firefox 17, but this caused problems in Moodle 1.9, so they implemented a workaround. See this Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=799502

Hi Melissa,

Dan (from Moodle) here. Unfortunately the firefox 'solution' for this can't determine if the Moodle site is 'fixed' or not, so its non-deterministic and so will be presenting the wrong useragent all the time (unless the user has disabled the about:config setting: general.useragent.complexOverride.moodle ).

Its difficult to decide what the best way forward from here. I suppose ideally that firefox setting shouldn't be used any more as users have had a while to upgrade their Moodle sites will be ok (the fix is applied to the latest versions of 1.9, 2.2, 2.3 and (soon) 2.4

But non-upgraded Moodle sites will be affected still, also i've no idea how quickly Mozilla could do that. For now a workaround for affected users is to set the about:config variable.

This is really a tricky one.

Perhaps we could map out the various combinations of Moodle/Mahara and the situation/workarounds for each?

Oops, missed 2.1 off that list.

To be clear: even if your moodle is upgraded, firefox will still be sending the 'old-style' user agent string.

Is it a possibility that we alter Moodle and Mahara to ignore the user agent hash check for a certain range of Firefox versions? Then people will need to upgrade both but at least it's one way out ...

Another solution (requiring that sites only upgrade Moodle) is that Moodle MNET code transforms the hacked version of Firefox 17+:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20100101 Firefox/17.0

to the unhacked version before sending the hash to Mahara:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Firefox/17.0

(we can do this safely by looking at the 17.0 at the end)

Perhaps it might be worth stepping back for a moment and asking what security value there is in checking that Moodle and Mahara receive the same User Agent string? Given that this string can be spoofed either by the user agent itself or by a proxy, so that it can be made to match or not match as a malicious actor requires, there is no value in checking it.

So I suggest that you implement all the solutions; i.e.:

a) Patch Moodle/MNET to work around the issue
b) Patch Mahara not to do the check

The Moodle and Mahara communities together will need to work out what they want us to do in terms of removing, or not, the workaround in Firefox.

Gerv

Hi Gerv,

From a web application perspective, getting users to upgrade their websites is hard. Really hard.

As Dan and Martin have pointed out, there are loads of schools admins rocking in corners clutching their precious Moodle 1.9, and likewise there are admins doing the same with Mahara 1.2. Neither group are likely to upgrade in a huge hurry.

So while it's a nice thought that we could use this to force them to upgrade, for many of them the changes in the systems between 1.9/1.2 and 2.3/1.6 can involve retraining rather non-technical staff which is likely to build resentment towards the projects.

Sadly, I suspect the quickest "selfish fix" for our immediate situation would be for Mahara to get the same treatment as Moodle has. However, that's not going to fix anything as it doesn't fix it for all the other applications utilising mnet. There are mnet integrations done with Drupal and other things too as far as I'm aware.

This situation rather sucks. :(

-M

Dan,

i´m running the latest Moodle 2.3.3 build. You wrote that a fix should already be implemented in the latest Moodle builds.
Did i get something wrong here?

Gerv,
i have to agree with Melissa. You won´t get the Admins to upgrade their Moodle or Mahara Installation to a major new release during the school year/semester. And i wouldn´t advise them to (especially Moodle 1.9->2.x is a bummer for non-IT-staff and needs preparation).

Werner

I agree with going for everything at once:

  - implementing the hack fix to ignore the hash (or transform the useragent) in Moodle
  - implementing the hack fix to ignore the hash (or transform the useragent) in Mahara
  - providing a nice little patch for people who can't actually upgrade (and notifying admins directly)
  - providing a page somewhere with good googleability ("Sorry, we could not log you into Mahara") that explains the workaround in Firefox (setting the config value).
  - get that page linked to from everywhere we can think of

I think we'll be OK with all that.

I have patches for both moodle and mahara that is essentially an ignore of the useragent at the exact point of checking the session.

I'm reluctant to rip all of the useragent code out up front as there may be other things intertwined.

Moodle patch. what's the moodle patch procedure?

Review for the patches says they are incomplete. Will upload fixed ones later

https://reviews.mahara.org/#/c/1885/

@Melissa:
> So while it's a nice thought that we could use this to force them to upgrade, for many of them the changes in the systems between 1.9/1.2 and 2.3/1.6 can involve retraining rather non-technical staff which is likely to build resentment towards the projects.

To be clear, the fix for the useragent has been applied to 1.9, so 1.9 users can upgrade to the latest 1.9.19+ to get this. It doesn't require a to 2.x upgrade. (http://git.moodle.org/gw?p=moodle.git;a=commit;h=6ab3a8525227db41895eea75f00d5ad177f719a8)

@Werner:
> i´m running the latest Moodle 2.3.3 build. You wrote that a fix should already be implemented in the latest Moodle builds.
Did i get something wrong here?

The fix to the original problem (incorrect firefox useragent check). However Firefox implmeneted a workaround for this bug which is helpful for users who have not upgraded, this workaround is what is now causing problems. This problem is *not yet* fixed.

Reviewed: https://reviews.mahara.org/1885
Committed: http://gitorious.org/mahara/mahara/commit/7277f3b24f7349b05e4c49ac054d345a51dd522e
Submitter: Hugh Davenport (<email address hidden>)
Branch: master

commit 7277f3b24f7349b05e4c49ac054d345a51dd522e
Author: Melissa Draper <email address hidden>
Date: Tue Nov 27 12:30:48 2012 +1300

    Remove useragent from sso session check (Bug #1082416)

    Due to an override for moodle sites in Firefox 17 the useragent
    in moodle and mahara cannot match, therefore jumping is broken.
    This does not remove the useragent data storage, just the check
    when the query for the sessions occurs in transfer and logout.

    Change-Id: I59a2e3fb1aea20027ce6cf24338440c866b56f58
    Signed-off-by: Melissa Draper <email address hidden>

Reviewed: https://reviews.mahara.org/1893
Committed: http://gitorious.org/mahara/mahara/commit/48920340775845377ebd63128f76b1c5396eea8d
Submitter: Melissa Draper (<email address hidden>)
Branch: 1.6_STABLE

commit 48920340775845377ebd63128f76b1c5396eea8d
Author: Melissa Draper <email address hidden>
Date: Tue Nov 27 12:30:48 2012 +1300

    Remove useragent from sso session check (Bug #1082416)

    Due to an override for moodle sites in Firefox 17 the useragent
    in moodle and mahara cannot match, therefore jumping is broken.
    This does not remove the useragent data storage, just the check
    when the query for the sessions occurs in transfer and logout.

    Change-Id: I59a2e3fb1aea20027ce6cf24338440c866b56f58
    Signed-off-by: Melissa Draper <email address hidden>

Reviewed: https://reviews.mahara.org/1894
Committed: http://gitorious.org/mahara/mahara/commit/6f4b4a8c563d37f3af201a62129c0b10ff2a469f
Submitter: Melissa Draper (<email address hidden>)
Branch: 1.5_STABLE

commit 6f4b4a8c563d37f3af201a62129c0b10ff2a469f
Author: Melissa Draper <email address hidden>
Date: Tue Nov 27 12:30:48 2012 +1300

    Remove useragent from sso session check (Bug #1082416)

    Due to an override for moodle sites in Firefox 17 the useragent
    in moodle and mahara cannot match, therefore jumping is broken.
    This does not remove the useragent data storage, just the check
    when the query for the sessions occurs in transfer and logout.

    Change-Id: I59a2e3fb1aea20027ce6cf24338440c866b56f58
    Signed-off-by: Melissa Draper <email address hidden>