"Leveraging XSS to get RCE in Textpattern 4.8.7" by Pentest Ltd

gaekwad · 2022-01-25 17:20:28

We received a comprehensive report from Paul Ritchie at Pentest Ltd relating to a cross-site scripting issue with Textpattern 4.8.7. Oleg fixed it, Stef verified it, and we rolled it into Textpattern 4.8.8. Pentest have provided more details here:

Leveraging XSS to get RCE in Textpattern 4.8.7

In short: please update your Textpattern sites to 4.8.8 as soon as possible.

jakob · 2022-01-25 17:56:32

Thanks for handling that information responsibly.

Presumably it also affects versions prior to 4.8.7?

Have I understood this correctly:

the attacker does not need access to the backend but they must pass a link to a someone who has access to the admin area and that user must click / interact with it while they are logged in. From then on the attacker can extract the relevant access credentials and influence the installation for as long as the textpattern user is logged in.

Bloke · 2022-01-25 18:03:57

It’s wonderful to deal with companies like Pentest who adhere to responsible disclosure, perform in-depth analysis that allow us to locate, verify and fix vulnerabilities, and engage in dialogue with us during the process.

As an addendum, a little more information on the plugin side of things:

As has been the case since they were first introduced, Textpattern plugins can be installed via compiled .txt files (compressed or uncompressed). Such plugin files are passed through the Plugin Verification step allowing you to see the code, help and language strings bundled with the plugin prior to installation. This feature allows you to inspect the code to verify you trust that the plugin does what it claims.

In more recent years, plugins can also be installed via plugin template (.php) format files and bundled (.zip) pathways. These are primarily supported as a convenience for developers, though some plugin authors do offer these type of file formats directly for installation, especially if the plugin requires bundled third-party libraries.

It is important to note that – even in Textpattern 4.8.8 – plugins installed from .php or .zip do not pass through the verification step. They are installed directly. Therefore it is imperative that you inspect and verify the authenticity of the code and its operation via your own tests before you install it.

Further, in recent Textpattern versions, plugins are stored and served from disk instead of from the database. This is for two reasons:

Performance (disk is less of a bottleneck these days than it once was).
Bypassing PHP restrictions. Many hosts disable eval() for very good reasons, and such hosting environments prevented plugins from being installed and/or executed.

A by-product of running plugin files from disk means – and this is still the case in v4.8.8 – that plugins are stored in a web-accessible location. Failure to adequately protect the plugins directory from the browser may mean plugin code can be executed directly by altering the URL.

For this reason, if you are running a flavour of Apache, it is strongly recommended that you rename .htaccess-dist in the textpattern/plugins directory to simply .htaccess. This step prevents plugin code from being accessed via the browser URL. For Nginx installations, a similar approach can be taken to set up web server directives that prevent code execution.

In your config.php file, you may also specify:

define('PLUGINPATH', '/path/to/your/plugins');

if you wish to move the plugins directory somewhere that is not web-accessible. Be warned that if any plugins bundle their own libraries that rely on front-end website access to the code (e.g. to JavaScript libraries) then these will not work after you take this step.

The situation is changing from Textpattern 4.9.0.

Textpattern 4.9.0 (currently ‘dev’) has had a radical alteration under the hood for plugin management. Although you must still protect the plugins directory using .htaccess (or move it by redefining PLUGINPATH) there are additional features and protections in place:

Plugins may be installed from URLs by dragging the URL into the text box.
ALL plugins – .txt, .zip and .php files (and URLs) are passed through the verification step.
ALL bundled content – code, language strings, help text, and supplemental files – are displayed in the verification step so you can see exactly what is going to be installed on disk/in the database.
Plugin files that are uploaded/unpacked are fingerprinted prior to the verification step. This fingerprint is recomputed and validated a second time when you proceed with the installation after verification. If the code or bundle has been tampered with in any way between upload and verification, then installation is aborted.

All the above is available in Textpattern 4.9.0-dev NOW.

As an additional convenience, plans are afoot to hook into our plugins.textpattern.com repository and offer seamless plugin upgrades directly from the Admin->Plugins panel, should a newer compatible version become available. We’ll communicate progress on this in due course.

gaekwad · 2022-01-25 18:08:41

jakob wrote #332492:

Presumably it also affects versions prior to 4.8.7?

That’s a fair assessment. I haven’t gone through the code to figure out which versions are affected, but it’s safe to assume many or most versions prior to 4.8.8 are affected.

the attacker does not need access to the backend but they must pass a link to a someone who has access to the admin area and that user must click / interact with it while they are logged in. From then on the attacker can extract the relevant access credentials and influence the installation for as long as the textpattern user is logged in.

I believe so, yes. That matches my understanding. I suspect Stef will have confirmation of this either way when he stops by.

I was a bit puzzled how it managed to be such a high CVE score / rating (>9) given the situation, but I’m not an expert in this stuff. I triaged and liaised with Paul at Pentest, his report was excellent and his credentials check out, so I have no reason to doubt what he’s saying. Oleg was able to reproduce and resolve it, Stef was second pair of eyes (and commented positively on the quality of Oleg’s patch), and it was all taken care of efficiently.

For completeness, the only small snag was our email system flagging the initial email as spam as their DNS wasn’t set up particularly well. I was pleased to be able to advise something (small) in return for Paul’s research: make sure your domain DNS has valid SPF, DKIM and DMARC records if you want your email to arrive safely more often than not.

Last edited by gaekwad (2022-01-25 18:14:45)

phiw13 · 2022-01-26 00:45:06

Good report without all the usual “the-sky-is-dropping-on-you” hype. Thanks.

Bloke wrote

In your config.php file, you may also specify: define('PLUGINPATH', '/path/to/your/plugins');

I did not get that path to work when I moved the plugin folder when Oleg made it possible (4.8.7 I think). What works for me:

define('PLUGINPATH', txpath.'/../core_plugins');

for a folder at the root of the site (domain.tld/core_plugins)

Bloke · 2022-01-26 00:53:29

phiw13 wrote #332498:

define('PLUGINPATH', txpath.'/../core_plugins');

Interesting. It should work with absolute paths but then it may depend on whether the host has permitted them or has security measures in place. Nice to know relative paths work at least.

We need to unpick this mess a little bit and find a way to allow front- and back-end plugins to run more safely. I also really want to find a way to merge this with the developer plugin cache path. Now we’re serving plugins from disk anyway, there’s not much difference between live plugins and in-development plugins, so having two separate disk-based paths seems to complicate things for no material gain.

Textpattern CMS

Textpattern CMS support forum

#1 2022-01-25 17:20:28