VaultWiki News

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.

While investigating another unrelated bug report on a client's site over the weekend, our developers discovered that with certain wiki permissions combinations, it was possible for moderated users to publish some changes to existing wiki articles before receiving a moderator's approval.

Additionally, using a variation of this vulnerability, non-moderated editors might be able to execute otherwise un-permitted changes under XenForo platforms.

To be clear: this is a security vulnerability, since it compromises the wiki moderation process, circumvents desired permissions, and can result in unwanted content or potentially malicious changes on your wiki.

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

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

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, as well as VaultWiki 3.x, but not VaultWiki Lite.

Details

This vulnerability can be executed by any user whose wiki edits would be sent to the moderation queue for approval.

Under XenForo, this vulnerability can be executed by any user who has permission to make edits, whether those edits require approval or not.

Alternative Mitigation

The only means of resolving this issue on XenForo platforms is to update to a patched release.

vBulletin administrators can close this vulnerability without updating to a patched release by removing permission to edit wiki articles from groups and users whose edits are also moderated.

Since VaultWiki 3.x has already reached its End-of-Life, a patch for that series has not been issued. If you are still running VaultWiki 3.x and you believe the issue details apply to your installation, the only remedies at this time are to update to a patched version or remove permission per the previous paragraph.

VaultWiki 4.0.1 is now available to all licensed customers. This release includes over 80 small improvements and fixes. Roughly 20% of these changes are related to the import system, which means that transferring data into VaultWiki 4 is a safer process than ever.

Custom Page Icons

With 4.0.1, we added the capability for wiki editors to replace the default icon for wiki articles with a custom image that will be used to represent the article in content lists, search results, feeds, previews, and more.

Editors have the option of choosing a pre-made font-based icon, an existing wiki image attachment, or an external image URL.

Release Notes

VaultWiki 4.0.1 should be usable on vBulletin-based and XenForo-based production sites.

VaultWiki 4.0.0 is now available to all licensed customers. Since RC 5 in November, we saw very few new bug reports and we really took our time with an extended QA period this release cycle, working closely with a number of communities, to make sure that the release was as solid as this implied. Thus, we are confident in this new release and have finally given VaultWiki 4 its Gold status.

Whatever bugs remain in the software should be minor at this point, and VaultWiki 4 should be considered viable for any sites running supported vBulletin or XenForo platforms at this time.

Wiki Feeds

With the gold release, we sneaked in a new wiki content-type, which we are calling Feeds. Users can make personal feeds that they use personally and can share with friends, or they can create global feeds that are intended for wiki readers at large.



You can think of a feed similar to a traditional article-based CMS or blog: rather than simply clicking wiki links or using directory listings to discover new content, feeds allow users to embed multiple wiki articles on the screen at once in sequence.

We intend to use this particular feature ourselves to become platform-independent of vBulletin CMS (which we currently use for VaultWiki News) and vBulletin Blogs (which we use for staff musings and occasional feature sneak peaks). We will be making this transition, as well as posting some tutorials on how to best use this feature to emulate both products, within the next few weeks.

Release Notes

VaultWiki 4.0.0 should be usable on vBulletin-based and XenForo-based production sites.

We hope you enjoy using it at least as much as we've enjoyed making it.

A few minutes ago, we launched an IndieGoGo campaign to increase awareness, improve our timeline, and get people involved in the process of bringing VaultWiki to Invision Power Suite and phpBB platforms.

To review the campaign, please go to: http://igg.me/p/vaultwiki-for-invisi...hpbb/x/9206010
We encourage all our visitors and customers to share this with everyone. The more people we get involved, the more VaultWiki can grow!

Some Details

With a stable 4.0.0 release just around the corner, we began to look forward at what new changes might be made for 4.1.x.

Before we get there, however, we'd seen in the past few months several forum platforms that VaultWiki does not currently support start testing and make public releases of fresh, new, and extendable versions of their software.

Specifically, we saw Invision Power Suite, which has already started beta testing its 4.0.0 version, and which is one of the last major commercial forum platforms that VaultWiki has yet to support. We also saw phpBB, perhaps the most popular free forum platform, which has just released its 3.1.x series and finally makes add-on integration as simple as our developers were used to with vBulletin or XenForo.

As we move forward towards VaultWiki 4.1.x, adding support for these platforms in a timely manner is critical, with respect to both to adoption rates of VaultWiki on new platforms and with planning future VaultWiki betas.

As we've come to learn, in order to expand quickly and without sacrificing attention in other areas of VaultWiki development, we need help from the community. That's why we've launched this fundraiser. The more people we get involved, whether by install base or by conversation, the more VaultWiki can continue to grow as a product that can benefit everyone.