FoF Pretty Mail exploit (CVE-2024-58303)

TheAbsoluteUnknown

Source: https://nvd.nist.gov/vuln/detail/CVE-2024-58303
Basically, malicious forum owners can use the extension to inject malicious code into email templates, which the potential fallout should hopefully be obvious.

rafaucau

TheAbsoluteUnknown I looked into this, and it is intended that users can add PHP code to templates. There is no way to fix this without breaking existing forums, as this behavior is by design. This extension is not going to be updated for Flarum 2.0 anyway, so I think we can leave it as it is.

FriendsOfFlarum 🔴 Dropped / Not required for 2.0

fof/pretty-mail - built into core now

rafaucau

As a quick follow-up: we could perhaps consider adding a simple flag in config.php to lock template editing from the admin panel. This wouldn't break existing forums, but it would prevent an attacker who hijacked an admin account from easily escalating to full server access. Legitimate admins would simply need to temporarily enable this flag in config.php whenever they want to make changes to their templates.

huoxin

rafaucau Would extension be able to use this feature as well?
Currently I am using https://discuss.flarum.org/d/32006-sudo-mode for my extension (in 1.x)

rafaucau

huoxin Not really. Sudo mode just asks for the password again, which doesn't stop an attacker who already knows the admin's credentials. The real issue here is separating forum access from server access - a forum admin simply shouldn't have access to the underlying server.

huoxin

rafaucau make sense, but actually I was asking if other extensions that also use php template could also lock their template based on the flag

rafaucau

huoxin Ideally, extensions should not expose editable PHP templates from the admin panel in the first place. Even if only admins can access it, forum admin access should not imply server-level code execution.

A config-level lock could mitigate this specific case, but I would treat it as a workaround for legacy behavior rather than something other extensions should rely on or copy.

rafaucau

Thinking about this a bit more, I think there may be a way to mitigate this without breaking backwards compatibility.

We could migrate existing templates from the database to files under storage, and make the admin UI read-only for this feature. The UI would only show where the files are located and explain that they should be edited via SSH/FTP instead.

That would preserve existing custom templates, while avoiding arbitrary PHP code execution directly from the forum admin panel.

rob006

There is already a flarum/extension-manager which allows installing packages with any arbitrary code. I would rather focus on protecting endpoints that could allow adding custom PHP code (sudo mode, separate superuser role, option to block this in config.php) than blocking it completely.

clarkwinkelmann

The consensus at the time that CVE was created (and only now I realize there were actually 2 different CVE numbers for 2 issues related to the same feature) was that this isn't really a vulnerability, as this is a core feature of the extension.

The CVEs were created by a third-party, without consulting with the FriendsOfFlarum team first.

I remember discussing this at the time, this might have been in the private FriendsOfFlarum Discord.

An official response we published at the time we found out about the CVE can be found here FriendsOfFlarum/pretty-mail40

Based on that, I don't think we took any additional action. We could definitely make the README more clear on the risks, which are not exclusive to this extension (the Extension Manager in particular is a much more dangerous extension in this category of risks). It would have been nice to have a variation of the extension with templates that don't allow custom code, but this would make the extension more complex, rather than just allowing customization of the blade template used by the existing internal templating system.