Our first security vulnerability

Here at UnifierHQ, we take user safety very seriously. This isn't some corpa talk (we aren't even a corporation to begin with, let alone a registered company), we work on features frequently that's designed to make keeping communities safe easier.

And that includes fixing security vulnerabilities as soon as we find them.

The vulnerability

Quoting from the advisory we published on GitHub:

A missing permissions check allows any user to run u!reload_services without privileges. This is an owner-only command which reloads all Unifier plugin scripts with either content_protection or content_processing services declared in their plugin metadata file (plugin.json). Although access to the bot as the owner or the host server is required to load a modified version of the scripts into the bot, continued reloads may lead to memory leaks (the magnitude depends on the memory Plugins use), which may cause the bot to shut down unintentionally due to excessive memory usage.

Fortunately, like I said here, this did not pose much of a security and safety risk, only an availability risk if people ran this command too much that it'd use up way too much memory and cause the bot to shut down.

Affected and patched versions

This vulnerability affects versions v1.2.4-patch (release 45) to v1.2.5-patch (release 48 legacy 1), and v2.0.0 (release 49) to v2.0.1 (release 51). Versions older than v1.2.4-patch are not affected as they lack Services support in Plugins, so they did not have this command with the vulnerability.

The vulnerability has been patched in v1.2.5-patch2 (release 48 legacy 2) and v2.0.2 (release 52).

If your Unifier instance uses a version within the specified ranges, we recommend you upgrade Unifier immediately to a safe version using u!upgrade.

Workarounds (without upgrading)

Although we heavily recommend upgrading to patch the vulnerability entirely, you can also uninstall all Plugins that have the listed Services. Users will still be able to run the command, but the command will do virtually nothing, except respond to the user that something's been done when in reality it hasn't.

Why it took us a while to disclose

We have to admit something: it took us way too long to disclose this vulnerability. Although it's only been days since we published a fix when we disclosed, it would've been optimal to disclose it as soon as we published the fix. And I, as the leader of the Unifier project, apologize for this delay.

This is the first time we're working on an actively maintained open-source project, so we had little experience with drafting and publishing security advisories. We had to do research, learning what in the world "Availability" and "Integrity" meant, and if we should put this at None, Low, or High when we're making our advisory. We should've done this research much earlier, instead of when we found the vulnerability, so we could've been better prepared.

In the future, we'll be disclosing vulnerabilities as soon as we find them and a patch is available (or if needed/ideal, after a while so that users can have time to upgrade to a patched version before disclosure), so everyone knows what's going on and what action they should take.