Setup

Vagrant

Setup MediaWiki Vagrant
- If you're running a firewall or efs, run `vagrant config nfs_shares no` before you `vagrant up` to turn off trying to use nfs for file sharing.
Use 1024M memory (the default). Less than this and VisualEditor breaks.
Enable roles: centralauth visualeditor pdfhandler svg parserfunctions checkuser echo flow multimediaviewer proofreadpage timedmediahandler
Add checkuser group to Admin user
Add to a file "tiffhandling.php" in settings.d/

<?php
$wgFileExtensions[] = 'tif';
$wgFileExtensions[] = 'tiff';
$wgTiffThumbnailType = array( 'png', 'image/png' );

Image

Download link: https://people.wikimedia.org/~csteipp/vagrant3_wikis.ova

Sha1: 3c15c498c8e723dd96778585473c3ca721a6e724

Download the VM
If you can, increase the memory to 2GB or more. That will make VisualEditor more reliable.
When started, the vm should use 10.11.12.13 as it's IP, setup hosts entries for the three wikis
- 10.11.12.13 login.wiki centralauthtest.wiki devwiki
- The main wiki to look at is http://devwiki. The other two wikis are for our SSO extension.
- Https (self-signed certs) work as they do on production, you should be redirected to https for login.
Access:
- The wiki Admin user's password is "vagrant". That user can adjust rights for any new users you create, using Special:UserRights
- You can login to vm via ssh using vagrant/vagrant

Priorities

Our wikitext -> html parsing
- Allowing users to edit wikitext and display their edits as html is probably the most basic feature of MediaWiki. The code is mostly in includes/parser/. We assume that any possible wikitext, when parsed to html, is safe from:
  1. executing javascript
  2. loading external resources that could be used to track readers
- The functionality of the parser can be extended with parser functions, allowing editors to use html-like syntax that calls extension code to process the input. In the vagrant config, the parserfunctions role with adds ParserFunctions. We distribute the ParserFunctions extension with the basic MediaWiki tarball, so those functions should be carefully looked at as well.
- If time allows (probably after Mediaviewer is done), assessing the lua template engine (Scribunto extension) would also be helpful. It returns wikitext which is parsed to html, but we would like to make sure the lua engine (luasandbox) can't be used to attack the host.
Upload, processing, and display of images/files (especially the handling of more obscure formats like svg, and Pdf/DjVu)
- By default, MediaWiki handles png, jpg, and gif files. The upload handling is in includes/upload/, and the handling of parsing and converting different formats is handled by code in includes/media/. The vagrant roles above add extensions and some config flags to setup file handling very similar to WMF sites:
  - timedmediahandler (ogg, ogv, oga, flac, wav, webm) - Add extensions MwEmbedSupport and TimedMediaHandler. Converts files using ffmpeg, and displays them using a variety of techniques.
  - svg (svg) - enable core's SVG processing. Uses rsvg, which is what the WMF uses in production.
  - proofreadpage (djvu) - enables core's DjVu processing, which relies on ddjvu, djvudump, djvutext, etc.
  - pdfhandler (pdf) - Adds extension PdfHandler. Processing is almost identical to core's djvu handling, but uses ghostscript and imagemagick for processing
  - settings.d/tiffhandling.php (tiff) - enable core's tiff handling
- On WMF wikis, images are served from a separate domain (upload.wikimedia.org), and use OpenStack's Swift for file storage. That is hard to emulate in vagrant, so it uses the default handling (images served from the same domain, and use the local filesystem for storage). This is probably easier to exploit, but we want to fix any issues in the default handling too.
- If time allows,
  - It would also be nice to look at img_auth, which is our way of serving images on private wikis.
  - The vagrant image has InstantCommons enabled, which allows including local references to images from commons.wikimedia.org.
VisualEditor extension
- This is the wysiwyg editor written by the WMF. It delivers a javascript editor for the user to edit the article text (in html), then translates the final html back into wikitext using the parsoid node.js service. The wikitext is then saved in a normal fashion, and users see the html that was parsed from the saved wikitext.
- It would be most helpful for this portion of the assessment to focus on the javascript editor and the parsoid service, since wikitext->html parsing is covered in #1.
CentralAuth extension (our authentication and single sign-on extension)
- Initially, the WMF added new wikis, and users could sign up for new accounts on each. This lead to some users creating the same username on lots of wikis, and some identical usernames used by different users on different wikis. The CentralAuth extension was written to allow users to:
1. Track accounts with the same username on different wikis, all owned by the same person, by unifying them into a "global account"
2. Allow users to login to any wiki using their global username and password, as long as their isn't an existing local user with the same username.
3. Automatically create their user on a new wiki if they don't exist there already when they login. If a user is logged in globally and visits a wiki where she doesn't have an account, the local account will be created automatically also.
- For the assessment, focus on the password handling, session management, single sign-on and autologin protocols
- In vagrant, enabling https is difficult, so this image will not have $wgSecureLogin like we use in production. Assume that in most cases, the login form and logged-in sessions are via https.
CheckUser extension (the extension that handles all of the User<->IP mapping for edits by logged in users, which we use for spam investigations mostly)
- For the assessment, the focus should be on can unauthorized users get access to the User-IP mappings
Mediaviewer - a lightbox viewer for images
- Added with the vagrant multimediaviewer role
Echo extension - notification messages for users
Flow extension - the conversation/collaboration tool that is replacing Talk pages.
- This extension is under active development, but would still be good to assess.

In the audit, we're hoping to cover 1-5. Others extensions will be audited as time allows.

Security Properties

See What are we trying to protect? for a list of security properties and objectives for MediaWiki.

For this assessment, we're less interested in failures in spam/vandalism mitigation and DoS attacks in general. Although WMF sites get a constant stream of DoS attacks and spam, we're able to mitigate them to an acceptable level with small config changes and volunteer effort.

Also note that we've specifically decided not to protect a few things:

For a default wiki install, we do not attempt to protect the user names of site users. The list of all username is available at Special:ListUsers, and the edit history and Special:Log show the usernames of users who edited or created accounts. Private wikis can restrict access to all but a few pages to prevent usernames from being displayed, and when possible MediaWiki will attempt to support wikis that wish to keep these private. However, this is not guaranteed, and shouldn't be counted on by private wikis.
Except on private wikis, all content is assumed to be publicly accessible. See also Security_issues_with_authorization_extensions.

Background

A good, although slightly dated description of MediaWiki's architecture: The Architecture of Open Source Applications vol. II. That should help the auditors understand core vs extensions, and how some of the major components are put together.