WordPress Newsletter Plugin Multisite Vulnerability
I have had the opportunity to work with the WordPress Newsletter Plugin from Tribulant, a plugin that rivals the free MailPress plugin, but with its own twist (and its own pricetag of $54.99 single license, $274.95 unlimited).
The WordPress Newsletter Plugin copy starts out by shouting:
A WordPress newsletter plugin which will, without a doubt, blow your mind away with its feature set…
And it does, after you take a look at one of its core features that they’re proud of:
Both PHP, HTML, CSS and WordPress shortcodes can be put into themes.
Newsletters: Themes Documentation
See anything wrong with that?
How about this in the Theme Editor screen:
You may use PHP code inside themes and any of the shortcodes/variables.
Exactly! PHP!?
The problem
You mean to say that any user with the right permissions, i.e. accesslevel: 10 (User Levels have been deprecated in WordPress 3.0), which stands for Administrator. Well that’s not a problem, right? You may be the only Administrator on your site.
Problems arise when you are NOT the only Administrator. This is especially true in Multisite environments, where you can have an infinite amount of Administrators. Sure, they all have separate tables in the database, and wouldn’t normally see one another’s blogs, they have their own WordPress security contexts. But, what they share is a common PHP user with all its access rights and privileges. Ouch!
So my Multisite users, with the help of WordPress Newsletter Plugin can in fact do this:
…and viola, with compliments:
This means that everything the current PHP user has access to is compromised, including the database.
Additionally, with the latest 3.3.8 version updates, Tribulant was kind enough to let Administrators give out power to any other user roles:
Full integration with the WordPress roles has been done. You can tick/check the roles which are allowed to have access to each individual section of the Newsletter plugin. Additionally, any custom roles added with a WordPress roles plugin like the WordPress Members plugin will show up here as well, dynamically.
So one wrong tick… tock… and boom!
Also, if an attacker (hacker) gains access to any of the admin accounts in WordPress (via privilege escalation, cookie hijacking, etc.), then with the help of WordPress Newsletter Plugin he/she can drop the database, read server files (exec( 'cat /etc/htpasswd' );
), in short, run any PHP code and potentially compromise the whole system. Of course if any of your plugin and theme files are writable by the PHP user then they’ll go for your Plugins or Theme Editor, which also supports PHP, which is why you always need to set the right permissions and make sure your PHP user is not almighty. Maybe it’s time for WordPress to remove the Theme and Plugin Editor (at least disable it by default via a CONSTANT), too.
The solution
A closer inspection of course reveals that the WordPress Newsletter Plugin uses eval()
in its code. TLDR:
The eval() language construct is very dangerous because it allows execution of arbitrary PHP code. Its use thus is discouraged…
wp-mailinglist-ajax.php:208: echo eval('?>' . $content . '<?php '); wp-mailinglist.php:315: echo eval('?>' . $theme -> content . '<?php '); wp-mailinglist.php:1052: echo eval('?>' . $content . '<?php '); wp-mailinglist-plugin.php:2863: echo eval('?>' . stripslashes($theme -> content) . '<?');
This is version 3.8.7, line numbers may not match later or previous versions, just search for the evil “eval”. If you’re realizing that your Multisite or even Singlesite (not pointing fingers at the public backend Demo at Tribulant) is at risk right now, replace all those lines with:
wp-mailinglist-ajax.php:208: echo '?>' . $content . '<?php '; wp-mailinglist.php:315: echo '?>' . $theme -> content . '<?php '; wp-mailinglist.php:1052: echo '?>' . $content . '<?php '; wp-mailinglist-plugin.php:2863: echo '?>' . stripslashes($theme -> content) . '<?';
You’ll end up with unevaluated PHP tags in your theme, those have to be replaced with HTML or shortcodes instead. And then wait with hope until these insecurities are removed at the source, and we can get back to enjoying the great plugin in a Multisite environment. Until then, I remain disappointed and strongly discourage irresponsible use of WordPress Newsletter with its powerful but dangerous features.
A long-term solution
I think that there is absolutely no point or advantage of giving front-end PHP capabilities. Things are bound to go horribly wrong, PHP is unforgiving and has no place in-mid HTML-based e-mail themes. In my opinion, shortcodes only are the proper way to go. If users are tech-savvy and confident enough to use PHP in WordPress Newsletter mail themes, they will have no problem wrapping their PHP into shortcode callbacks inside functions.php
, and value the much-needed layer of security.
The conclusion
The Newsletter: PHP Variables documentation (if you ever get to read that before buying) does not warn you if you’re planning on running this on Multisite. In fact, nowhere in their front-facing pitch does it say that this script is in any way dangerous for Multisite. And I would have never realized in time if not for some other problems (hardcoded header images in the default templates) which I was to solve, making me look into these themes in the first place and seeing <?php
tags… and then I fell off my chair.
Tribulant
I’ve written to Tribulant’s support 72 hours ago, warning them of my forthcoming vulnerability disclosure, which would have affected their public Demo (it’s been patched now). Tribulant’s CEO Antonie Potgieter has approached and handled the matter with utmost responsibility, acknowledged the flaw of the PHP feature and was ready to discuss potential solutions. A new version of WordPress Newsletter Plugin will be rolling out which does away (at least by default) with the evil eval
s. Antonie stated that the company will make it a point to release a patch by the end of this week.
Update February 18th, 2012
An update has been published, getting rid of the dangerous functionality. I haven’t checked it out yet, will do so in a couple of days.
Thank you for your post.
And thank you for your help with this, we appreciate it.
We’ll release an update of the Newsletter plugin shortly.
Very informative site overall by the way.
All the best,
Antonie
We have released v3.8.9 which eliminates the use of PHP code in the themes, only HTML, CSS, short codes, etc… will be supported.
You can see the announcement here: https://blog.tribulant.com/mailing-list-plugin/newsletter-plugin-v3-8-9/ (there is a link to the release notes as well).
All the best,
Antonie
Thanks for the update, Antonie.
There is another severe security problem with Tribulant’s plugin, and that is that they are severely out of touch with best security practice.
They use a plugin called TimThumb. TimThumb is a hack from before WordPress 2.9, and is completely unnecessary.
Some plugins and themes insist on using it anyway, which is only a moderate risk with the default configuration.
However, Tribulant appearse to have modified the TimThumb configuration to enable an extremely insecure feature. Here is the default from TimThumb 2.8 and onwards:
if(! defined('ALLOW_ALL_EXTERNAL_SITES') ) define ('ALLOW_ALL_EXTERNAL_SITES', false); // Less secure.
And here is what I found in a website using Tribulant’s plugin:
if(! defined('ALLOW_ALL_EXTERNAL_SITES') ) define ('ALLOW_ALL_EXTERNAL_SITES', true); // Less secure.
Woops.
I cannot claim for sure that this is Tribulant’s fault, it is conceivable that some other vulnerability has been abused and used to change the TimThumb default configuration.
However, using TimThumb in the first place is a fup-uck.
Thank you for your comment, Jan.
There was a problem with the TimThumb script but they secured it.
We also ensured that the TimThumb script used inside all our plugins and specifically our WordPress Newsletter plugin is secure and there aren’t any security risks with it.
Let us know if you need any assistance.