Disabled features are still accessible by visiting their URI directly

Bug #618634 reported by Andrew Nicols on 2010-08-16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Melissa Draper

Bug Description

If I disable a plugin (e.g. Resume), then the menu items for it disappear (correctly).
However, if I visit the URI for that plugin (e.g. /artefact/resume) on my site, I can still access, view, modify and submit information stored within the artefact.

Marking this as a security vulnerability because the plugin has been disabled but this is being circumvented.

Andrew Nicols (dobedobedoh) wrote :

Here's a potential fix. I haven't double-checked that all plugin pages define the type and name we test against here, but from a quick think about it, it's the only way which abstracts things as much as possible.

The only bit I don't like is that we call table_exists, which requires ddl.php which adds more bloat.

Hi Andrew,

Yeah we've always known about this, but haven't effectively communicated that disabling plugins is just hiding them in the UI. An easier fix (which admittedly might not meet with your expectations) would be to change the language strings that say 'enabled' and 'disabled' to just say 'visible' and 'hidden' instead.

If we go with your patch, we'll have a lot more work to do. First, I'm not 100% confident that those SECTION_PLUGINNAME, etc, constants are used consistently at the moment - I think they're only needed for showing the page help, so we'd have to go through and check that they're always used in the right place. This could also get complicated because there are plenty of places where a plugin is used but it's not on one of that plugin's pages. This patch won't stop them from being used in these cases, so it will also disappoint people who expect 'disabled' to really mean disabled.

Ideally we should require plugins to be uninstallable (there is another bug report for this somewhere), so that admins who really want to properly disable them on their site can do it confidently.

Changed in mahara:
status: New → Opinion
security vulnerability: yes → no
visibility: private → public
Changed in mahara:
importance: Undecided → Medium
milestone: none → 1.4.0
status: Opinion → Confirmed
Changed in mahara:
assignee: nobody → Hugh Davenport (hugh-catalyst)
Changed in mahara:
assignee: Hugh Davenport (hugh-catalyst) → nobody
François Marier (fmarier) wrote :

Quick fix for 1.4: changing the langstring from "enable/disable" to "show/hide"

tags: added: bite-sized
Melissa Draper (melissa) wrote :

There are 3 other strings that use the same language (enable/disable)

$string['pluginenabled'] = 'Plugin enabled';
$string['plugindisabled'] = 'Plugin disabled';
$string['pluginnotenabled'] = 'Plugin not enabled. You must enable the %s plugin first.';

I'm leaning towards changing them for consistency, but I'd like agreement from others who know the system better.

Changed in mahara:
assignee: nobody → Melissa Draper (melissa)
status: Confirmed → In Progress


They're probably the confirmation messages you get when you click the enable/disable links, try it out on Site Administration->Administer Extensions.

I'm still not 100% convinced the text should be show/hide, I think that could be confusing too, so if you can think of something better, go for it. While you're on that page, I think it'd be good to add some text at the top explaining that you cannot completely uninstall or disable a plugin, you can only hide it in the interface.

Melissa Draper (melissa) on 2011-05-04
Changed in mahara:
status: In Progress → Fix Committed
Changed in mahara:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.