Possible https to http downgrade

Bug #685942 reported by Ruslan Kabalin on 2010-12-06
258
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mahara
High
Ruslan Kabalin
1.2
High
Ruslan Kabalin
1.3
High
Ruslan Kabalin

Bug Description

Interesting that with both, bug #646713 and bug #684190, we overlooked the most obvious and relatively sensitive issue.

Even though $cfg->wwwroot might be set 'https://somemaharasite', depending on apache config, user may still be able to use insecure page for logging in by entering 'http://somemaharasite' in the web browser address field, then, upon logging-in, user credentials will be passed through insecure connection first, before sever respond with redirection to https secured page.

This is valid for other pages after logging in - at any time used may switch back to insecure connection by typing 'http://somemaharasite/somedir/somepage.php'.

This can be fixed by ensuring that $_SERVER['HTTPS'] is set when $cfg->wwwroot = 'https://...', otherwise redirecting user to the same page using https.

CVE References

François Marier (fmarier) wrote :
Changed in mahara:
milestone: none → 1.4.0
status: New → Confirmed
Ruslan Kabalin (rkabalin) wrote :

With the current httpswwwroot removal changes, it is probably the time to release this fix as well.

summary: - If wwwroot is defined to use https, it is not the fact that it is being
- used.
+ Possible https to http downgrade
Changed in mahara:
status: Confirmed → In Progress
Changed in mahara:
assignee: nobody → Ruslan Kabalin (ruslan-kabalin)
visibility: private → public
Changed in mahara:
status: In Progress → Fix Committed
Changed in mahara:
status: Fix Committed → Fix Released
milestone: 1.4.0 → none
Iñaki Arenaza (iarenaza) wrote :

I didn't notice the fix was incomplete before because I was also bitten by this Ubuntu cron bug: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/790538

Now that cronjobs are run, I've noticed that my Mahara cronjob is run but nothing appears in the logs. I run the cronjob from the command line using the same config you can find in the wiki, and I have just switched to HTTPS for the whole Mahara site.

I've traced the issue to the commit for this bug, as it tries to make a redirect to secure URLs if the wwwroot is configured for HTTPS but the request is not done using HTTPS. When you run Mahara cron from the command line, HTTPS is obviously not set, so init.php tries to redirect the execution to the secured URL. But HTTP redirection doesn't work in command line (for obvious reasons), so the execution dies inside redirect().

We need to check if we are running in command line mode before checking HTTPS and trying to redirect the request to the secure URL. The attached patch (for 1.3_STABLE, that's what we are running right now) should do the trick. I think the patch should also be applied to 1.4_STABLE and master, but I don't have the time to test them right now.

Saludos.
Iñaki.

Ruslan Kabalin (rkabalin) wrote :

Hello Inaki, I thought it has been fixed already, see https://reviews.mahara.org/#change,303

Iñaki Arenaza (iarenaza) wrote :

Hi Ruslan,

yup, it's been fixed for 1.4_STABLE and master, but not for 1.3_STABLE (see http://gitorious.org/mahara/mahara/blobs/1.3_STABLE/htdocs/init.php#line194 ). I thought 1.3_STABLE was still supported, am I right?

Saludos.
Iñaki.

François Marier (fmarier) wrote :

Hi Iñaki,

1.3_STABLE is supported for security fixes only. However, given that this "cron not running" bug is a regression caused by a security update, we should fix it in 1.3.7.

Bug #794490 is the bug that tracks this problem (and that's what change I991f51d2cc9272e5f33e5f4b7486d3565924d8c7 should have been pointing to). I have reopened it with a milestone of 1.3.7.

Cheers,
Francois

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers