Page MenuHomePhabricator

Security hole through RSS/Atom feeds of Recentchanges
Closed, InvalidPublic

Description

Author: palaniappanc

Description:
There is a security hole that allows parts of a read-protected ($wgGroupPermissions['*']['read'] = false;) wiki's content to be accessed by anyone. Through the RSS/Atom feeds of Special:Recentchanges. The feed isn't password protected.

The feed's URL for any wiki can be figured out easily by anyone with a couple of days' experience with MediaWiki.

A temporary workaround for this problem is to set the feed limit to 0, as suggested by Hojjat in MediaWiki-General.

I think you should put up an alert on the front page (mediawiki.org), and warn people of this problem, and suggest the temporary solution.

Thank you.


Version: 1.11.x
Severity: critical

Details

Reference
bz13107

Event Timeline

bzimport raised the priority of this task from to Unbreak Now!.Nov 21 2014, 10:05 PM
bzimport set Reference to bz13107.
bzimport added a subscriber: Unknown Object (MLST).
Huji added a comment.Feb 22 2008, 12:43 PM

With r31184, I provided a way for wiki admins to turn off the syndication feeds totally, when they desire. My knowledge of syndication feeds is limitted but if there is no standard way to authenticate inside feed readers, then I think the only solution available is to turn them off when there are good reasons (such as when read permission is restricted).

palaniappanc wrote:

The IRC conversation about this bug

Attached:

Created attachment 4675
Human readable version of the same IRC log

Attached:

soxred93 wrote:

Hmm...even when using a version of MW downloaded a few weeks ago, turning read to false turns off the feed as well. Are you sure you are using the latest version of MediaWiki?

Works for me.

http://office.wikimedia.org/w/index.php?title=Special:Recentchanges&feed=rss

The reporter seems to be under the impression that the URL is insecure because
it doesn't contain a password. The opposite is true. Access to the URL is
authenticated by cookies. Putting the user's password in the URL would expose
it to accidental leaks.

Note that if Special:Recentchanges were in $wgWhitelistRead, then the RSS feed
would be available. So don't put Special:Recentchanges in $wgWhitelistRead.

The feed is served with CC:private and Vary:cookie, so there is no cache-based
leak.

palaniappanc wrote:

Soxred93,
The version I'm using is 1.11.1. I downloaded it about 7-10 days back. I can upload the .tar.gz file here if you want to check. And yes, I had turned read to false. $wgGroupPermissions['*']['read'] = false;

(In reply to comment #4)

Hmm...even when using a version of MW downloaded a few weeks ago, turning read
to false turns off the feed as well. Are you sure you are using the latest
version of MediaWiki?

Tim Starling,
I am not under the impression that the URL is insecure because it doesn't contain a password. At that point in the IRC chat, I remembered that some feeds contain a username and password in the URL to allow content to be served to registered users. But since I was able to read the content via my RSS reader though the Special:Recentchanges page's content was supposed to be protected (can't read it without logging in and $wgWhitelistRead is set to false - see below) AND the URL didn't contain any username/password, I made that comment.

I'm not saying that u/ps in URLs is a secure method. But I do believe that serving protected content only in the presence of a username/password is more secure than serving that content anyway (discounting the fact that the u/p could be discovered by someone else).

I've pasted the relevant parts of LocalSettings.php and DefaultSettings.php below. Am I missing something here?

LocalSettings.php:
#permissions
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['user']['read'] = true;
#because of RSS bug
$wgFeedLimit=0;

DefaultSettings.php

  1. Pages anonymous user may see as an array, e.g.:
  2. array ( "Main Page", "Special:Userlogin", "Wikipedia:Help");
  3. NOTE: This will only work if $wgGroupPermissions['*']['read']
  4. is false -- see below. Otherwise, ALL pages are accessible,
  5. regardless of this setting.
  6. Also note that this will only protect _pages in the wiki_.
  7. Uploaded files will remain readable. Make your upload
  8. directory name unguessable, or use .htaccess to protect it.

$wgWhitelistRead = false;

(In reply to comment #5)

Works for me.
http://office.wikimedia.org/w/index.php?title=Special:Recentchanges&feed=rss
The reporter seems to be under the impression that the URL is insecure because
it doesn't contain a password. The opposite is true. Access to the URL is
authenticated by cookies. Putting the user's password in the URL would expose
it to accidental leaks.
Note that if Special:Recentchanges were in $wgWhitelistRead, then the RSS feed
would be available. So don't put Special:Recentchanges in $wgWhitelistRead.
The feed is served with CC:private and Vary:cookie, so there is no cache-based
leak.

brion added a comment.Feb 25 2008, 5:53 PM

Is your feed reader also your browser? (Eg, Safari, Opera, Firefox.) In this case, your login session in the browser will apply just as much to the feed reader, and you're just seeing an authenticated page because you're in an authenticated session.

It's possible that some third-party feed readers also in some way share cookies with associated browsers (perhaps by piggybacking on Internet Explorer), so check into that.