VaultWiki News

Earlier this month, we received a bug report in which a user had noticed that his wiki was sometimes giving the wrong users credit for certain tasks. After investigation, our developers noted that this bug could be leveraged to perform permissions escalation and inject HTML or Javascript into wiki content.

This issue affects all VaultWiki versions 4.0.0 Alpha 1 - 4.0.6, including VaultWiki Lite.

On October 14, we published the following Patch Level releases to resolve this issue:

• 4.0.6 Patch Level 3
• 4.0.5 Patch Level 3
• 4.0.4 Patch Level 3
• 4.0.3 Patch Level 3
• 4.0.2 Patch Level 6
• 4.0.1 Patch Level 9
• 4.0.0 Patch Level 8
• 4.0.0 RC 5 Patch Level 7
• 4.0.0 RC 4 Patch Level 8

If you are not already, we highly recommend that all users running VaultWiki 4.x in a production environment upgrade to a patched release as soon as possible to .

Last week, a user reported slow database activity that appeared to be related to normal VaultWiki usage. After an investigation, our developers determined that such a situation was the result of a security vulnerability.

Since this vulnerability is connected to normal forum and wiki activity, it does not require malicious intent for damage to result. At its core, it acts as a Denial of Service amplifier, which, after as little as 1 concurrent request to the vulnerable action (depending on other variables), can cripple the ability to perform basic tasks such as search or create posts for an unspecified length of time.

This issue affects VaultWiki versions 4.0.4 - 4.0.6, including VaultWiki Lite. This issue affects vBulletin-based installations only.

We have published the following Patch Level releases to resolve this issue:
4.0.6 Patch Level 2
4.0.5 Patch Level 2
4.0.4 Patch Level 2

We highly recommend that all users running VaultWiki 4.x under vBulletin in a production environment update to a patched release as soon as possible.

Over the weekend, while reviewing code for a solution to an unrelated bug report, our developers theorized a security vulnerability in the template feature under XenForo platforms and confirmed it later that day.

This vulnerability can be exploited by a patient attacker to inject HTML or Javascript into a wiki page via multiple specially-crafted templates with a success rate of approximately 1 in 50,000 uncached views of that wiki page. Of course, a long-lived page cache lowers the success rate with respect to total views and can approach 0% over short periods over time. However, once the attack is successful the wiki page can also be cached in the succeeded state and thereafter have a success rate of 100%.

This issue affects VaultWiki versions 4.0.0 Gamma 1 - 4.0.6, but does not affect VaultWiki Lite. This issue affects XenForo-based installations only.

We have published the following Patch Level releases to resolve this issue:

• 4.0.6 Patch Level 1
• 4.0.5 Patch Level 1
• 4.0.4 Patch Level 1
• 4.0.3 Patch Level 2
• 4.0.2 Patch Level 5
• 4.0.1 Patch Level 8
• 4.0.0 Patch Level 7
• 4.0.0 RC 5 Patch Level 6
• 4.0.0 RC 4 Patch Level 7

We highly recommend that all users running VaultWiki 4.x under XenForo in a production environment upgrade to a patched release as soon as possible.

As of the end of this week, VaultWiki 4.0.6 is now available to the general public. This is mostly a maintenance release, fixing over 30 documented bugs. A few improvements to the software have also been added.

XenForo Tagging

VaultWiki 4.0.6 includes support for the Content Tagging feature introduced by XenForo 1.5. Users may tag wiki content so that they appear in tag clouds and other tag-related searches.

BB-Code Flexibility

Over time, VaultWiki has added a large number of BB-Code tags to supported forum platforms, some with popular names among BB-Code developers. In some cases, it was common for users to need to choose between VaultWiki's BB-Code and a similarly named BB-Code by another developer.

Under VaultWiki 4.0.6, it is now possible to rename VaultWiki's BB-Codes without sacrificing or compromising their functionality (although if you have used them already, you would have to update those posts). In this way, you can still use VaultWiki's BB-Code even if you install another with a conflicting name.

BB-Codes will now appear in XenForo's built-in BB-Code Manager, available since XenForo 1.3.

Except for XenForo < 1.3, VaultWiki's own Syntax Manager has been removed. The settings from this admin page are now located in the BB-Code Manager provided by each forum platform.

In addition, VaultWiki's Wiki Links settings that allowed the renaming of some tags has been removed. Wiki Links BB-Codes are now renamed directly via the BB-Code Manager.

Release Notes

The current release is VaultWiki 4.0.6, which should be usable on vBulletin-based and XenForo-based production sites.

VaultWiki 4.0.4 is now available to all licensed customers. This is a maintenance release with a small handful of improvements, bug fixes, including the fixes for the two security issues discussed later in this announcement.

New Search Filters, Sitemap Improvements

VaultWiki 4.0.4 allows users to search your wiki based on the kinds of wiki content they want (or don't want) to see. Users can filter attachments, templates, and other kinds of pages from searches. Search results will now also treat synonyms and feeds as candidates for search results.

Feeds now appear in the wiki's sitemap files. This makes entries via the new feature more accessible via third-party search engines.

Add Multiple Articles to Containers

VaultWiki 4.0.4 has updated the "Add Existing" menu for containers like books, categories, and feeds. You can now select multiple articles at a time, which makes these tasks much easier and faster, especially when you have a new category that you want to connect to 50 other pages.

More Vulnerabilities

VaultWiki versions 4.0.1-4.0.3 contain a Denial of Service Amplification vulnerability in the Custom Icon system (see: Photo of Loris), which a malicious user can exploit to place all available PHP child processes into a busy state fairly quickly.

This issue is resolved by the following Patch Level releases:

• 4.0.3 Patch Level 1
• 4.0.2 Patch Level 4
• 4.0.1 Patch Level 7

We also discovered that the last set of patches for VaultWiki 4.x only partially resolved one of the addressed security issues.

This issue is resolved by the following Patch Level releases:

• 4.0.0 Patch Level 6
• 4.0.0 RC 5 Patch Level 5
• 4.0.0 RC 4 Patch Level 6
• 4.0.0 RC 3 Patch Level 7
• 4.0.0 RC 2 Patch Level 7
• 4.0.0 RC 1 Patch Level 7

We highly recommend that all users running VaultWiki 4.x in a production environment upgrade to a patched release as soon as possible.

Release Notes

The current release is VaultWiki 4.0.4, which should be usable on vBulletin-based and XenForo-based production sites.

VaultWiki 4.0.3 is now available to all licensed customers. This is a maintenance release with a small handful of improvements and bug fixes.

This release contains an updated SSL certificate so that the Admin Panel can continue to make secure connections to vaultwiki.org when retrieving information about product updates. A valid certificate ensures that your server is actually talking to the real vaultwiki.org site when making these connections.

PCRE Backtrack Vulnerability

4.0.3 includes improvements when dealing with extremely large strings of text, such as articles with 500,000 characters. These changes workaround a potential security issue involving PCRE, where extremely long strings of text might prevent PCRE from functioning correctly and thus potentially malicious content might not be cleaned.

Since the best fix involved changes to the way VaultWiki handles text at a rudimentary level, this issue is ONLY PATCHED BY 4.0.3.

This vulnerability affects all versions of VaultWiki 2.x, 3.x, and 4.x, including VaultWiki Lite.

If you cannot upgrade to 4.0.3 to resolve this issue, then you should take the following precautions:

• Learn what your PHP installation's configuration value is for pcre.backtrack_limit. This might appear in your php.ini file. If this does not appear in that file, the default value is as follows:
  
  • For PHP 5.3.8 and higher: the value is 1,000,000
  • For PHP 5.3.7 and lower: the value is 100,000
• Check the following VaultWiki settings:
  
  • VaultWiki: Content Types > Maximum Characters in Page Content
  • VaultWiki: Content Types > Maximum Characters in Discussion Comments
• Make sure that the values of each setting is set to a lower amount than your pcre.backtrack_limit. If one of the settings is higher, you should lower it to maintain the security of your installation, or increase pcre.backtrack_limit to a value higher than each setting.
• Check your Special:LongPages page for existing pages that are longer than pcre.backtrack_limit.
• These pages remain a vector for attack while they are longer than this limit. You must shorten these pages.

Mirror-Injection Vulnerability

On vBulletin installations, VaultWiki versions 4.0.1-4.0.2 contain a potential HTML/Javascript injection vulnerability that we are naming the "Mirror-Injection Vulnerability."

This issue only affects VaultWiki versions 4.0.1 - 4.0.2 Patch Level 2, including VaultWiki Lite. This issue does NOT affect XenForo-based installations of those versions.

Thus, we have also issued the following Patch Level releases:

• 4.0.2 Patch Level 3
• 4.0.1 Patch Level 6

Release Notes

The current release is VaultWiki 4.0.3, which should be usable on vBulletin-based and XenForo-based production sites.