« Better AJAX Form Processing | Home | Improve Your Phplist RSS-to-Email Feature By Using Simplepie Rather Than Onyx »
Restoring the Style and Class Support Eliminated by WordPress MU 1.2.3
By Greg | July 30, 2007
The latest version of WordPress Multi-User hobbles styling flexibility for end users by stripping out classes, CSS styles, even ALT attribute. This huge step backward in terms of usability has appeared under the mantle of ‘security fix’, but as far as I can tell, this is not a security fix at all. Here’s how to restore lost WPMU functionality, and where to find the updated code that fixes the real bugs in this area that are still shipping with both WordPress and WordPress MU.
What Happened to My Styles?
Authors who rely on the multi-user version of WordPress may have been surprised recently to discover that their ability to apply inline styling in their posts was suddenly removed: no more nicely-floated images, no more custom padding or margins, not even so much as a simple ALT attribute. Some of those authors will already have been relying on custom styling for some time, and will therefore have a collection of old posts where they know it was previously working just fine. But if any of those poor souls makes the mistake of going back to an old post, opening it up for editing, and then re-saving it, they will discover that the code which previously worked just fine is now being forcibly stripped out by WordPress.
Actually, it isn’t just end-users who are affected: administrators, too, suddenly have suddenly found that their carefully crafted styling on WPMU pages or blog entries can be wiped out by a re-save, and certainly no new styling can be added. I hope you saved a copy somewhere else, because all you’ll find is a plain DIV where there used to be a DIV with a CLASS attribute; the same with SPAN and any other tag that might have held custom styles or attributes.
WordPress is well-known for draconian alterations to the code entered by users, but what’s going on here? Why has WPMU suddenly become so keen to tell users “non!“?
So Is it Really a Security Fix?
The culprit is the WordPress MU 1.2.3 update (the WPMU equivalent of the regular WordPress 2.2.1 update), which shipped with a modified kses.php file that now strips out attempts by end users to style their own posts using CSS (or to include such niceties as ALT or TITLE). Why would such a major step backwards in terms of usability appear with so little warning or prior discussion?
As it turns out, the lead developer for WPMU (I think there’s just one, Donncha O’Caoimh, but please use the comments form to correct me if I’m wrong) made the changes to kses.php after reading an article published in August 2006 about a security exploit going by the name of variable width encoding. To be safe from this exploit, Donncha eliminated a whole swath of allowable markup from blog posts, ensuring that an important part of this exploit would be unavailable to any would-be evildoers intent on mucking about with a WordPress MU installation via cunningly crafted code entered in an author’s editing window.
Don’t get me wrong, Donncha is clearly an exceedingly capable programmer, and the WordPress community (WPMU especially) has a lot to thank him for. Donncha is the first to admit, though, that the intricacies of such security exploits are not his strong suit. As it turns out, in this particular case, I think Donncha jumped the gun a bit. Actually, it’s worse than that: wiping out WordPress support for styles and a bunch of other stuff is a bit like throwing away your Ferrari because you read an article that said you could have a bad accident if you over-inflate your tyres. What would be a more circumspect approach than just trashing that cruddy old Ferrari because you might over-inflate your tyres? Well, first you could find out how to avoid over-inflating your tyres…and just make sure you don’t do that. Keep the Ferrari, drive safely, and everybody goes home happy.
In this particular case, as far as I can tell, there is no danger of over-inflated tyres anyway. Or, more to the point, there is no danger of unencapsulated attributes sneaking out of a tag (the heart of the variable width encoding exploit). Why? Because the exploit doesn’t just require carefully crafted content to be slipped into a tag attribute (like, say, CLASS, STYLE, ALT, etc.) — it also requires unescaped/unentified double quotes somewhere else. If you have just one of these, but not the other, the exploit doesn’t get off the ground. This was actually pointed out in a comment on the original exploit article on the same day it was published, and immediately acknowledged by the author — again on the same day the article was published, back in August 2006.
So does WordPress permit any unescaped/unentified double quotes in any other relevant place? As far as I am aware, there is just one place: between CODE tags. Everywhere else, WordPress has always made a big deal of how it automatically 1) enforces XHTML rules (which would include those prohibiting unescaped double quotes within attributes) and 2) ‘texturizes’ plain double quotes into curly double quotes. (By the way, does anyone know why WP insists on numerical entities for curly quotes, rather than the perfectly serviceable named equivalents like ” and “? Just a pet peeve…) In other words, WordPress already ensures that there will not be any available double quotes floating around for the exploit to use. What’s more, the old kses.php already prevented any extra attributes from being included within CODE tags anyway, so for that one exception where WordPress doesn’t step in to mess with double quotes, we were already covered.
One caveat: I’m not an XSS (cross-site scripting) security expert either. Maybe there’s something else I’ve missed here. But I’m fairly certain I can understand at least this much: without a spare unescaped/unentified double quote running around somewhere, there is no attack vector. And WordPress doesn’t have those anyway, except between CODE tags, and CODE tags haven’t been allowed to have any extra attributes for years anyway.
So are you safe running the previous kses.php? I can’t say definitively yes or definitively no, but I can say that I don’t see any way in which the article Donncha references could be used to justify a move to the newer, feature-nuking kses.php.
Yes, There are Bugs Here — But Different Bugs!
But there is one final fly in the ointment…
It turns out that the version of kses.php which ships with both WordPress MU and the ordinary WordPress includes several bugs anyway, the first of which was reported back in April 2005. Modified versions of the filtering routines are now available which fix this and other bugs, as well as speeding up the code and cutting it down in size by roughly 50%. However, it’s not a simple matter of just dropping in the fixed file and replacing your current file, because 1) WordPress prefixes all its functions with ‘wp_’ and 2) the newer kses.php has replaced some little-used function calls with inline code. That means it will take a bit of effort to 1) rename the functions in the less buggy code, and 2) verify that the elimination of certain functions won’t impact other parts of WordPress, which might make calls to those eliminated functions.
So, if you’re looking to improve both the security and the performance of WordPress in this area, the answer is not simply to wipe out usability by eliminating any possible use of user-defined styles. Instead, the answer is to incorporate the bug fixes currently available for kses.php, ensuring that the rest of WordPress can work correctly with the less buggy code. And let users have their styling back!
Find Additional Information
Learn more with a Google search specifically on the ‘WordPress MU’ site:
Bookmark and Share:
August 29th, 2007 at 4:11 am
[...] a look at this Article on Restoring Style to WPMU for some rational discussion on this [...]
September 26th, 2007 at 12:39 am
Is there step-by-step instruction on how to get this back into wpmu? im kind of a noob and i need div’s back in my wpmu v1.2.5 installation….
help!
September 26th, 2007 at 9:09 am
Hi Chase,
No step-by-steps here, but the good news is that if you’re running 1.2.5, it’s fairly straightforward to restore the lost functionalty via a plugin, rather than just via using the older kses.php. See Donncha’s note on how to do it here on his blog.
All the best,
Greg
September 29th, 2007 at 2:18 am
[...] block to the right of a post, how do i get that functionality back, anyone? This might help: Restoring the Style and Class Support Eliminated by WordPress MU 1.2.3 | Where Else to Put It? __________________ Get Your Own Forum/Site Menu Firefox Extension Now! A Web [...]
February 21st, 2008 at 7:33 pm
[...] After a crap load of googling I found it was some sort of security measure implemented by wordpress. I found some more info about this here. [...]
January 6th, 2009 at 9:50 pm
Hey Greg,
What’s the latest on this with WPMU 2.6+ (and I suppose 2.7, but I’m avoiding it at the moment)?
Is it still removed functionality for WPMU, or does Wordpress have it now? I’m having trouble with TinyMCE in non-post textareas, and of course, problems with embedding Youtube.
Burton
January 10th, 2009 at 2:08 pm
Hi Burton,
I stopped working with WPMU a year or so ago, so I’m afraid I’m none the wiser as to what the latest version might have in store for you.
All the best,
Greg
May 11th, 2009 at 4:24 am
It’s very frustrating working with MU now. Yes, 2.7 strips code and so does the new update I installed today.
I’m going around in circles looking for a fix for it. Google sent me to this page, but no fix here, as is the case wherever it’s being discussed. You don’t dare ask for help in the MU forum about this issue.