Page MenuHomePhabricator

[SimpleSecurity] Feeds from private namespaces and pages not restricted at all
Open, NormalPublic

Description

Other URL: http://wiki.wikimedia.it/w/index.php?namespace=102&days=30&title=Speciale%3AUltimeModifiche&feed=atom
RC and new pages feeds from the Direttivo: namespace, restricted to members of the board and sysops, are actually visible for everyone, even logged out. http://wiki.wikimedia.it/w/index.php?title=Speciale:Utenti&group=Direttivo
I once found a private page crawled by Google several years ago, this may be the reason.

Currently using: MediaWiki 1.18.1 (from Debian repo), PHP 5.3.3-7+squeeze15, SimpleSecurity 5.0.4.

Yes, I know that the extension is now marked as unstable etc. Seems worth filing anyway. (Added to cc: WMIT board and sysadmin; original extension author; Daniel, who usually manages LockDown extension for WMDE, IIRC.)


Version: unspecified
Severity: normal
URL: http://wiki.wikimedia.it/w/index.php?namespace=102&days=30&title=Speciale%3AUltimeModifiche&feed=atom

Details

Reference
bz46843

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 1:39 AM
bzimport added a project: Security-Extensions.
bzimport set Reference to bz46843.
bzimport changed Security from none to Software security bug.
Restricted Application changed the visibility from "Public (No Login Required)" to "Security (Project)". · View Herald TranscriptNov 22 2014, 1:39 AM
Restricted Application changed the edit policy from "All Users" to "Security (Project)". · View Herald Transcript
Nemo_bis created this task.Apr 3 2013, 11:48 AM

Workaround now in place: $wgFeed = false;

Restricted Application changed the visibility from "Security (Project)" to "Custom Policy". · View Herald TranscriptNov 24 2014, 9:28 PM
Restricted Application changed the edit policy from "Security (Project)" to "Custom Policy". · View Herald Transcript
demon removed a subscriber: demon.Aug 19 2015, 4:40 PM

This security bug has been open > 3 months, and it appears that nobody intends to work on the issue. Unless someone begins working on this in the next 2 weeks, I am going to mark the extension with {{Security Alert}} and make this bug public.

This security bug has been open > 3 months, and it appears that nobody intends to work on the issue. Unless someone begins working on this in the next 2 weeks, I am going to mark the extension with {{Security Alert}} and make this bug public.

It would be better to make it public only after putting the workaround in place, at least in master: can't the extension set $wgFeed = false for the wiki?

Wow, I was bad at following up on this. Clearly nobody is maintaining this extension, and it would be irresponsible not to warn people that the extension has holes in it. I took a look at the extension code, well it does try to do clever things intercepting SQL queries with $wgSecurityUseDBHook, it doesn't take caching into account (Revision::loadText() looks for page text in memcached/apc first with key revisiontext:textid:<textid here>, which is the code path the parser would take when rendering templates), and the check can be bypassed depending on if the revision was previously cached for a different user. The RCFeed is probably caught up in an even higher level cache. I imagine something similar applies to diffs as well.

To that end, I plan to publish this bug on either Monday or Tuesday, unless someone stands up right now and says they intend to fix this extension.

[As an aside, wikimedia italia no longer uses this extension, they moved to LockDown at some point]

Making this bug public. I am also going to put a warning on the extension page, and send an email to mediawiki-l (Not sure about the email, I don't think we usually do that, but it seems like it would be good practice to announce the insecurity if we're going to make the bug public)

Bawolff changed the visibility from "Custom Policy" to "Public (No Login Required)".Jul 19 2017, 3:29 AM
Bawolff changed the edit policy from "Custom Policy" to "All Users".

Now that I made this public, I don't know if I should change the status of this bug, maybe remove the security tag and have it off the Security workboard? I don't think it should be closed, since its a valid bug in the MediaWiki-extensions-SimpleSecurity project, but it maybe should not be cluttering up Security - i don't really know.