As of 36171312ef0 we have:
$wgCacheDirectory = false;
$wgLocalisationCacheConf = [
'class' => 'LocalisationCache',
'store' => 'detect',
'storeClass' => false,
'storeDirectory' => false,
'manualRecache' => false,
];
And in LocalisationCache we have:
case 'detect':
if ( !empty( $conf['storeDirectory'] ) ) {
$storeClass = 'LCStoreCDB';
} else {
$cacheDir = $wgCacheDirectory ?: wfTempDir();
if ( $cacheDir ) {
$storeConf['directory'] = $cacheDir;
$storeClass = 'LCStoreCDB';
} else {
$storeClass = 'LCStoreDB';
}
}
Which in effect means for someone on a shared host using default config, they are probably going to use /tmp for their localisation cache directory.
This is a bad idea because having multiple wikis with different extensions/mw versions use the same localisation cache directory means they are going to step over each other, since this creates files named like l10n_cache-en.cdb (which doesn't have wiki id in it). This makes sense if you have a consistently configured wiki farm or manual localisation cache refreshes. It makes less sense in a generic shared host (Just try and install MediaWiki on tool labs and see the permission fatals).
More importantly though, this has a security impact. Another user on the system can insert an evil cache file (You don't really even need a race condition, just chose a really obscure language).
The most obvious thing to do would be to change one of the raw html messages, in order to XSS (Actually editing Common.js seems a bit harder, since you would need to force a RL cache purge somehow, but i can confirm this works for other various raw messages).
However, since these fields get run through unserialize(), you can actually execute arbitrary code as the web user
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4