VaultWiki News

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.

Yesterday, our developers discovered a vulnerability in the wiki's moderation system. The vulnerability affects all versions of VaultWiki after 2.1.1, including all versions from 4.x and 3.x series and most of the 2.x series. The issue does not affect VaultWiki Lite, which has never included support for moderated wiki content.

Today, our developers discovered that a Javascript-injection vulnerability from 2.x and 3.x that was previously thought to be patched was still exploitable in patched versions, and subsequently the 4.x series. This issue affects all versions of 2.x, 3.x, and 4.x, but not VaultWiki Lite.

Today, our developers discovered that an SQL overflow vulnerability from 2.x and 3.x that was previously thought to be patched was still exploitable in patched versions. This can easily be exploited to potentially crash one or more server processes. This issue affects all versions of 2.x and 3.x, but not VaultWiki Lite.

While performing an audit of previous disclosures today, our developers discovered another easily exploitable HTML/Javascript injection vulnerability in the VaultWiki 4.x series when installed against vBulletin 3.x. This issue affects all versions of 4.x under vBulletin 3, including VaultWiki Lite.

Yes, you counted right: that's 4 vulnerabilities.

We have published the following Patch Level releases to resolve the three issues that are relevant to supported releases:

• 4.0.2 Patch Level 2
• 4.0.1 Patch Level 5
• 4.0.0 Patch Level 5
• 4.0.0 RC 5 Patch Level 4
• 4.0.0 RC 4 Patch Level 5
• 4.0.0 RC 3 Patch Level 6
• 4.0.0 RC 2 Patch Level 6
• 4.0.0 RC 1 Patch Level 6

Details

Given certain permissions combinations, it is possible that a non-moderator user may be able to approve edits by any user. When exploited, a user whose edits are normally moderated may be able to change the approval state of his or her own edits. Further, a user whose edits are normally moderated may be able to perform history modifications without needing approval for those changes.

Do I Need to Apply This Patch?

The moderation vulnerability has existed in every version of VaultWiki that supports queuing edits by untrusted users for moderation. If you use the moderation queue for any wiki content, you should apply one of these patches.

A Javascript-injection vulnerability has existed in every version of VaultWiki that includes the TABLE, DIV, or SPAN BB-Codes. If you have these BB-Codes enabled in your Wiki Code Manager or Syntax Manager, you should apply one of these patches.

An HTML/Javascript-injection vulnerability has existed in every version of VaultWiki 4.x when installed on vBulletin 3. If you run vBulletin 3 and you allow comments in any part of the wiki, you should apply one of these patches.

There are no patches for VaultWiki 3.x or 2.x series, as those versions are long retired.

For users who cannot update to a patched VaultWiki 4.x release, you should:

• Ensure that untrusted users who would normally be moderated only have view permissions within the wiki -- that they cannot post or otherwise modify wiki content, AND
• Ensure that untrusted users who would normally not be moderated do not have any access to the History tab or related actions, AND
• Ensure that TABLE, DIV, and SPAN BB-Codes are not allowed to parse in wiki or non-wiki content via your Wiki Code Manager (2/3.x) or Syntax Manager (4.x).

For users who are using VaultWiki 2.x or 3.x and cannot update to a patched release, in addition to the above, you should:

• Modify the permissions for all usergroups so that no one has permissions to view any kind of Special pages, AND
• Modify the permissions for all usergroups so that no one has permissions to view the History tab.

For users who are using vBulletin 3 and cannot update to a patched release, in addition to the above, you should:

• Modify the permissions of all usergroups so that no untrusted users have permissions to post new comments or edit existing comments.

Earlier in the week, our developers discovered a minor permissions escalation vulnerability in VaultWiki 4.x series that affects installations on the vBulletin platform.

This issue affects all versions of VaultWiki 4.x on vBulletin, including VaultWiki Lite. This issue does NOT occur on XenForo platforms.

Please note that this vulnerability has been labeled as minor, because a user cannot knowingly exploit it, and because a user cannot escalate beyond the "Yes" values of their most permissive usergroup.

Nevertheless, we have published the following Patch Level releases to resolve this issue:

• 4.0.2 Patch Level 1
• 4.0.1 Patch Level 4
• 4.0.0 Patch Level 4
• 4.0.0 RC 5 Patch Level 3
• 4.0.0 RC 4 Patch Level 4
• 4.0.0 RC 3 Patch Level 5
• 4.0.0 RC 2 Patch Level 5
• 4.0.0 RC 1 Patch Level 5

Details

In versions prior to 4.0.2 only, permissions from a user's secondary member groups will still be applied even if the user's primary usergroup does not allow the user to receive permissions from secondary groups (common for "banned" usergroups). Thus, the user's permissions escalate to those allowed by secondary member groups.

In 4.0.2 only, permissions from a user's secondary member groups are completely ignored. Thus, if a secondary member group provides the Never value for the same permission that the primary usergroup provides a Yes value, the Yes value is used instead. Thus, the user's permissions escalate to those allowed by the primary usergroup.

Both variations are resolved by the newest patches.

Do I Need to Apply This Patch?

If you are running VaultWiki 4.0.1 or lower on vBulletin and any of your users in "banned" usergroups have secondary member groups or might in the future, we HIGHLY recommend updating to one of the aforementioned patched releases. If you are running VaultWiki 4.0.2 on vBulletin and you use "Never" values for permissions, we HIGHLY recommend updating to 4.0.2 Patch Level 1.

If these conditions do not apply to you but you are running VaultWiki 4.0.2 on vBulletin and you simply rely on secondary member groups to receive wiki permissions, we recommend that you update to 4.0.2 Patch Level 1 to regain the ability to perform actions within the wiki.

VaultWiki 4.0.2 is now available to all licensed customers. This is a maintenance release with over 85 bug fixes, as well as a handful of minor improvements.

Security Updates & Even More Patches

With the recent Patch Level releases for earlier versions, we have done some rethinking regarding security for various functions. As a result, VaultWiki 4.0.2 offers new permission settings for actions that did not have them before or that previously relied on other settings. Additionally, 4.0.2 now checks an article's protection status for more actions than prior versions did.

We believe that VaultWiki 4.0.2 is our most secure release ever. However, while considering the security improvements for 4.0.2, we noticed the existence of 2 existing permissions-workaround vulnerabilities: one in the feeds system, a feature that was added in 4.0.0, and one that has existed in the books system since the 2.x series.

The feed vulnerability makes it easy for malicious users to vandalize many feeds.
The books vulnerability requires specific permissions combinations to create an unexpected condition which may allow users to vandalize a book's table of contents.

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

• 4.0.1 Patch Level 3
• 4.0.0 Patch Level 3
• 4.0.0 RC 5 Patch Level 2
• 4.0.0 RC 4 Patch Level 3
• 4.0.0 RC 3 Patch Level 4
• 4.0.0 RC 2 Patch Level 4
• 4.0.0 RC 1 Patch Level 4

The feeds vulnerability affects all supported versions of VaultWiki 4.x since 4.0.0 (stable), including VaultWiki Lite. The books vulnerability affects all paid versions of VaultWiki 4.x, 3.x, and some 2.x versions, but does not affect VaultWiki Lite.

If you have the Feeds or Books features from these versions enabled in a production environment (default: enabled), we HIGHLY recommend upgrading to 4.0.2 or updating to one of the aforementioned patched releases.

New permission settings in 4.0.2 allow for more fine-tuned control over both feeds and books in the newest release, but for the Patch Level releases we had to make changes to some permission calculations that may have undesired results for some use cases. For this reason, we recommend using 4.0.2 rather than one of these patches if you can.

Alternatively, you can prevent vandalism to your content by disabling the Feed and Book content-types entirely until you are able to upgrade. In the wiki's Admin Panel, go to Structures > Content Types, and ensure "Feeds" and "Books" are disabled.

Open Graph Support

VaultWiki 4.0.2 includes built-in support for social networks that use Open Graph technology. This support means improving tracking of wiki content with Open Graph-based analytics and cleaner, more useful previews when sharing pages on Facebook or Google+. Shares via Twitter should now use Twitter cards.

These improvements apply automatically, whether or not your site already has built-in sharing functions for any social media site. The reasoning is that users can share your wiki content anyway if they know the URL, and this content should always be presented as attractively as possible to their followers.

Special:Credits

VaultWiki 4.0.2 includes a new Special:Credits page, which uses the same permissions as the Special:Version page. This new Special page lists the names of developers and other people who have contributed to VaultWiki over the years.

Special:Credits also includes a "Special Thanks" section, which includes the names of those who have previously contributed donations towards VaultWiki development, specifically fulfilling "Infamy" and higher-level perks from our IndieGogo campaign that ended in January.

Special:Credits currently only names donors from this IndieGogo campaign. If you have made a donation directly to VaultWiki development in the past, and you would also like your name included, please shoot pegasus a PM.

Development Notes

We would like to apologize for the delay in the release of 4.0.2. Due to the recent "Moderation Security Vulnerability" that was discovered around the expected release date, we delayed 4.0.2 in order to make further improvements to security.

We have also been having trouble recently with our in-house packaging system, which uses a custom PHP script that interacts with our Mercurial repository. With the past few regular updates, we have had issues where the checkout process for a release would use excessive server resources and often never finish. These issues came to a culmination about a week ago, and we had to refactor and redesign how changesets were compiled and retrieved, or we would not be able to generate any release packages going forward.

We were finally able to resolve these issues without a costly server upgrade, and we reduced our system's packaging time by as much as 4,100%.

Notes on the Earlier Release of 4.0.0 Patch Level 1

After the updates to our system mentioned above, we noticed that the recent 4.0.0 Patch Level 1 was actually a clone of 4.0.0 RC 5 Patch Level 1. Thus users of 4.0.0 who then updated to Patch Level 1 may have noticed regressions in features and bug fixes, and users who upgraded from 4.0.0 RC 5 would have noticed little change.

We would like to apologize also for this inconvenience.

4.0.0 Patch Level 3 now takes precedence over PL 1 anyway, and it is based on the expected version. Users of this version may wish to run the upgrade script again to ensure that the database is on the correct version as well.

Note that this issue should not apply to anyone who is already using 4.0.1 or higher.

Release Notes

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