Slashdot Mirror
New Zero Day Disclosed In WordPress Core Engine
Trailrunner7 writes: WordPress security issues have for the most part involved a vulnerable plug-in, but a Finnish researcher has disclosed some details on a zero-day vulnerability he discovered in the WordPress 4.2 and earlier core engine that could lead to remote code execution on the webserver. Juoko Pynnonen of Klikki Oy reported a new and unpatched stored cross-site scripting vulnerability in the platform; a similar bug was patched this week by WordPress developers, but only 14 months after it was reported. The vulnerability allows an attacker to inject JavaScript in the WordPress comment field; the comment has to be at least 66,000 characters long and it will be triggered when the comment is viewed, Pynnonen said.
"An unauthenticated attacker can store JavaScript on WordPress pages and blog posts. If triggered by an administrator, this leads to server-side code execution under default settings," Pynnonen said. "A usable comment form is required. It looks like the script is not executed in the admin Dashboard, but only when viewing the post/page where the comment was entered. If comment moderation is enabled (the default setting) then the comment won't appear on the page until it has been approved by an admin/moderator. Under default settings, after one 'harmless' comment is approved, the attacker is free from subsequent moderation and can inject the exploit to several pages and blog posts."
"An unauthenticated attacker can store JavaScript on WordPress pages and blog posts. If triggered by an administrator, this leads to server-side code execution under default settings," Pynnonen said. "A usable comment form is required. It looks like the script is not executed in the admin Dashboard, but only when viewing the post/page where the comment was entered. If comment moderation is enabled (the default setting) then the comment won't appear on the page until it has been approved by an admin/moderator. Under default settings, after one 'harmless' comment is approved, the attacker is free from subsequent moderation and can inject the exploit to several pages and blog posts."
I know it's fun and all to make fun of WordPress, and it is indeed a piece of garbage for multiple reasons. But this seems more a fault of highly liberal error handling on the part of Web browsers and MySQL.
From what I understand, MySQL truncated the input passed in without throwing any complaints that data was being lost.
Second, if the HTML pages were served under the more secure application/xhtml+xml media type, the compromised page wouldn't have been usable, because the malformed syntax would have produced a fatal error, instead of silently corrected (this is specified in HTML5, which IE supports now, woo).
I've seen more security vulnerabilities with text/html's silent fixing of errors than I can count, including a notable XSS attack because someone thought you don't need to HTML-encode URIs in hyperlinks... but this leads to funny behavior even with valid URIs like <http://example.com/doSomething?run©destination=baz> (if parsed as HTML, a copyright sign magically appears instead of the URL parameter you were intending).
Wonder what the public key field is for?
The vulnerability was already patched, just hours after being disclosed. WordPress 4.x applies security updates automatically.
For better or worse, WordPress is the most popular CMS and this makes it a prime target. Just like Windows.
Re-read the summary. It is a little more complex than you may realize.
Attacker inserts malicious JS code into a comment box.
JS code is viewed and thus executed by site's administrator.
JS code was specifically crafted to modify/edit PHP files on the server - a common function of WordPress, allowing the live editing of templates and plugins.
JS code then requests the newly modified PHP files from the server.
So you have no contact with the software for the past 6 years but you are convinced you know everything about it. Great.
People go to the shiny sites. If they see older-looking sites, they're less likely to stick around, particularly if it doesn't have the nice features that the newer sites have.
For all the problems that PHP has, I don't see many nearly as many sites going up built on other platforms, in large part because they're playing catch-up and are still largely years behind. .NET is probably the closest, but when you look at the number of free or even inexpensive sites running Windows, it pales in comparison to the PHP-based sites.
Add to this that WordPress is by far the easiest of the major CMS platforms to manage, and it gets even worse. I manage a couple of WordPress sites and a Joomla site. WordPress largely Just Works(TM). Joomla works for basics, but every time I want to get beyond adding a menu item, it becomes a whole new learning process.
You can never go home again... but I guess you can shop there.
Anyway, Wordpress is by far the most popular CMS, and it's not just the shiny interface. Ease of development. Problem are the developers who don't know even how to code, much less bother to RTFM. I don't deny that Wordpress sites can be a mess, but that's mostly to poorly designed plugins "developers" stuff. I use WPML and Timber, everything else is coded by me and my team.
Wordpress core is as secure, and faster than any other popular PHP CMS. Larger attack base so sometimes shit happens.
Imagination is more important than knowledge. Having both makes one a genius.
How can this WordPress vuln be exploited to further leverage access to the underlying Operating System.
A not-so-shiny CMS doesn't mean that the website you create with it can't be shiny. Those are two separate things. Of course, the actual website must be shiny, but the CMS should be (if you ask me) secure and trustworthy.
It doesn't have to be like this. All we need to do is make sure we keep talking.
Doesn't "zero day" only really apply to attacks, not vulnerabilities themselves?
After all, every vulnerability is a zero day vulnerability on the day it's discovered/disclosed (and actually it seems there's no indication of whether or not WordPress already knew about this one).
And this one was disclosed yesterday (and may have been discovered much earlier) so it's at least a one-day vulnerability now.
systemd is Roko's Basilisk.
The company I work for has decided to drop WordPress and develop a new CMS that does exactly what we need in-house. We mostly need static pages so there's no need to load an entire application platform (which is what WordPress is, essentially) every time anyone wants to view a page. Plus, WordPress does what it does slowly, plus we need tons of plugins (which eat even more performance) to get the functionality we need, plus many WordPress plugin authors think "best practice" is where you find a good doctor.
.htpasswd.)
Sure, it's going to take some time to develop but we can take the 20% of WordPress's functionality we actually need, cover the functionality WordPress doesn't offer natively without relying on modules of questionable quality and have a web-facing dynamic codebase that's so small we can be reasonably certain it's not vulnerable. (Essentially, the only PHP code on the published website should be a simple session management script so we can put content behind a password with more flexibility than
Despite writing everything ourselves we still expect to save money in the long term, simply because WordPress generates so much work for both our employees and our server. It's okay for a basic blog if you can babysit it but anything beyond that becomes a nightmare.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Because it's easy to install and maintain, it has millions of free templates and plugins and it's highly flexible.
Because small startups cannot AFFORD a custom coded CMS, themes, plugins or TRAINING.
Small startups/businesses in my experience are majority of wordpress users and their money is better spent on marketing, paychecks, and everything else that's needed to get the project off the ground.
I can literally set you up with a site and a ecommerce system in 20 minutes for FREE - that's why. The site that will be functional and professional looking.
The guy I work for now is doing sales of his own brand product. All his sites are in wordpress including the shop site. All of these were made by "clueless" people (in terms of IT knowledge) and he's doing $35k USD a month in sales after 1 year of doing it.
It's a small startup, and if wordpress didn't exist - his business wouldn't exist and salaries for 4 people wouldn't exist.
Wordpress has pretty good support as well. Updates are released often, and on dashboard you get notified of those updates - after which you do 2 clicks - done. Up2date, vulnerability gone. If they don't fix known bug, cool - hire somebody to fix it for you.
I know slashdot people like to shit on wordpress, PHP etc., but hundreds of thousands of businesses are on internet because of wordpress. It's a great CMS.
Internet is not only geek's playground anymore. Common people are on it now and are running their own internet business thanks to wordpress/joomla, facebook apple and the likes. But I also know average slashdot nerd don't care or understand much about how things work outside of what he does for a living.
And all this can be prevented if administrators simply adding one line to their wp-config.php
define('DISALLOW_FILE_EDIT', true);
Wordpress provides a large amount of hardening functions like this, others allow the overriding of default file permissions of uploaded documents to 644 instead of 755 to prevent execution of uploaded scripts.
Developers need to educate themselves on the software they are provides to beat learn how to administrate it.
"discovered in the WordPress 4.2 and earlier core engine"
WordPress is on version 4.2.1 and makes automatic nightly updates and if comment moderation is turned on fully and always then this is not an issue.
Keep up-to-date.
Moderate comments.
Both of these practices are good for other reasons.
Prevent execution of uploaded scripts? PHP scripts do not need execute permissions in order to run them. Other scripts can generally be executed as arguments to shell programs, such as "/bin/sh $FILEPATH", if you want to execute those programs in the context of the server rather than simply provided crafted code to a client.
Your reference to that define is also silly. That's an application-level setting setting a value that the core engine uses to determine permissions. Once someone is allowed to execute any PHP code through the application (which is exactly what this vulnerability is), they can clearly do so without using the Wordpress core interface. PHP kind of has that functionality built in.
The real problem is that almost all installations of Wordpress ensure that their files are editable by the web process user in order to use the auto-update feature. That ensures that *any* vulnerability instantly owns your entire Wordpress installation. It serves almost no other purpose. If the web process user cannot edit the core PHP files, then Wordpress cannot update itself, and neither can any injected scripts. I will grant however, that once you allow executable PHP in database-stored content, it doesn't matter much whether the files are editable or not, because the database storage becomes the tool of the attack.