If you have not yet updated to v1.6.2 or later, do so immediately. The details of the vulnerability are public, and your forum could be maliciously exploited.
Affected versions:
- v1.5.0 to v1.6.1 - ⚠️ Affected
- v1.4.1 and below - ✅ Not affected
Upgrade instructions:
# Update to latest version
composer update --prefer-dist --no-dev -a -W
# Verify that you're on v1.6.2
composer show flarum/core
# Clear cache
php flarum cache:clear
Preface
On Friday 18 November 2022 at 11:57 UTC, we received a report of a critical cross-site scripting (XSS) vulnerability in Flarum core through huntr.dev, affecting versions from v1.5.0 to v1.6.1.
This vulnerability is related to the process of setting page titles client and server side, and the possible conversion of title strings into HTML DOM nodes.
The details of this vulnerability were disclosed on the Flarum Discord's team channel at 12:08 UTC. The vulnerability's CVE score was 9.0, which is an extremely high CVE score.
This was patched through a combination of efforts from multiple developers and pushed to the core's main branch at 21:09 UTC. After verifying that the patch worked as expected and didn't have noticeable effects on other areas of core and bundled extensions, it was released as v1.6.2 at 22:21 UTC.
What caused the vulnerability?
Flarum's page title system allowed for discussion title inputs to be converted into HTML DOM nodes when rendered (visiting a discussion page). This change was made in v1.5.0 and was not noticed.
This allowed for any user to type malicious HTML markup within discussion title user input, either through a new discussion o renaming an existing one, and have this execute on client browsers. Entering faux-malicious HTML markup, such as <img src=x onerror=alert(document.domain)> resulted in an alert box appearing on the forum. This attack could also be modified to perform AJAX requests on behalf of a user, possibly deleting discussions, modifying their settings or profile, or even modifying settings on the Admin panel if the attack was targeted towards a privileged user.
The estimated CVSS vector for this vulnerability is CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H, resulting in a CVE score of 9. See the CVSS score breakdown.
A security advisory has been published on GitHub detailing information of the vulnerability: https://github.com/flarum/framework/security/advisories/GHSA-7x4w-j98p-854x. Waiting for a CVE to be issued.
CVSS breakdown
Attack vector: network
This attack is performed over a network without physical or local access required. The network does not have to be adjacent.
Attack complexity: low
The attack can be performed relatively simply and affected all forums, despite their individual configurations. It is repeatable under all conditions.
Privileges required: low
On a default installation of Flarum, users can create discussions after confirming their email address. This means that the only permissions required to exploit this vulnerability are a confirmed user account.
User interaction: required
For the vulnerability to be exploited, a user must open the malicious discussion within their browser.
Scope: changed
The vulnerable component is the Flarum forum. The impacted component is the user's browser, therefore the scope has changed.
Confidentiality impact: high
An impacted user's details could be fully retrieved by the attacker via a malicious AJAX request.
Integrity impact: high
An impacted user's details could be changed by the attacker via a malicious AJAX request.
Availability impact: high
If a forum administrator was impacted, a malicious AJAX request could modify forum settings on the Admin dashboard and result in a full forum denial of service. This could be by injecting broken Javascript code into the custom header resulting in a broken forum frontend.
How was the vulnerability fixed?
When setting the page title, we now prevent having the title evaluated through a temporary HTML element that was previously used to properly display raw HTML entities. This temporary element was within the scope of the browser's window, hence would execute Javascript within it and could access secrets within the page's Javascript scope (such as browser cookies).
Now, we use a DOMParser which has scripting disabled and is in a separate context from the window element. This prevents XSS attacks and allows raw HTML entities to be properly displayed. A more appropriate fix for the raw entities display issue will be looked into in further releases (see flarum/framework3685).
For more info, please see the commit that fixes this vulnerability: flarum/frameworked0cee9
What did we do right?
All available core developers jumped on the report to patch the vulnerability as soon as possible, an initial patch was proposed within a couple of hours and a final patch received the first approval within 7 hours, after thoroughly looking for the root cause and how it was introduced in the first place.
What could we improve?
At the time of the discovery, no online developers had the ability to draft a security disclosure on GitHub. This would have provided us with a secure way to attempt to develop a patch together and review the code more easily. Instead, we used a public PR which is less than ideal.
At the time of release, we struggled for some time with branching off and sub splitting from our monorepo for a lack of documentation and expanded use in our CLI utility.
How can we prevent this from happening again?
A JavaScript automated test suite could have helped pick up on the introduced issue which was not noticed during reviews. There is already work in progress in implementing Jest for one of the next releases. Automated tests will have a massive effect on avoiding these problems in the future.
