Over the past several days, while helping clients manage migrations from MediaWiki, we received reports of a possible performance issue. It turned out that this issue was actually quite insidious, because under the right circumstances and
completely unprovoked by any external malicious intent, XenForo was able to use VaultWiki to launch a DDoS (distributed denial of service) attack against itself, while using normal forum traffic as pawns to carry out the attack.
We immediately patched the issue from VaultWiki's side, and have released Patch Level releases for Release Candidates in the VaultWiki 4.x series:
- 4.0.0 RC 4 Patch Level 1
- 4.0.0 RC 3 Patch Level 2
- 4.0.0 RC 2 Patch Level 2
- 4.0.0 RC 1 Patch Level 2
We highly recommend that all users running VaultWiki 4.x in a production environment upgrade to a patched release as soon as possible.
This vulnerability affects all supported versions of VaultWiki 4.x, including VaultWiki Lite. It does not affect VaultWiki 3.x.
Details
This attack cannot be launched by any malicious user against your forum. It occurs when an administrative task in VaultWiki that requires deferred.php functionality returns an error response and causes a chicken-and-egg problem, because deferred.php is not equipped to handle error responses.
For XenForo sites, there are elements in both XenForo and VaultWiki that contribute to make the attack particularly unyielding, but we have patched the issue from VaultWiki's side. Note that it is not possible to halt the attack once it begins in XenForo without making manual changes to the database; even temporarily disabling VaultWiki will not reliably stop the attack.
Furthermore, ongoing attacks have been known to result in race conditions that have the potential to increase the size of some database tables and that eventually result in memory limit errors throughout the website while VaultWiki remains enabled. These runaway database entries are not the focus of this patch, but the race condition should be mostly avoided by closing the attack vector. The unwanted database entries will be automatically cleaned by an upgrade script bundled with a future release (Patch Level releases do not utilize the upgrade process).
The attack is also possible under vBulletin, but it is possible to halt the attack once it begins in vBulletin by disabling VaultWiki.
If you were previously under attack and stopped it, it is possible for the attack to 'reboot' at unexpected times in an unpatched environment.
Whether you are currently under attack or not, the best defense is to upgrade to a patched version. In a patched release, VaultWiki will be able to detect a scenario where its deferred tasks are being used to launch a DDoS attack and will automatically prevent those tasks from executing.
Temporary Mitigation
If you cannot upgrade at this time, and you believe you are under a deferred.php or wiki_ajax.php?c=deferred attack, you should be able to mitigate an attack manually by executing the following MySQL command:
Code:
UPDATE vw_deferred SET completed = 1
Note that this will stop all currently queued deferred tasks from running, such as cleanup tasks, and will likely affect the integrity of some wiki data. This option should only be used as a last resort.