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?
And still we keep on using Wordpress. When will people start looking beyond a nice and shiny interface and put quality (which includes security) at the top of their priority list. When you made the first selection with that criterion, you can look for the most fancy interface. And don't give me the excuse of 'but my web editors have to be able to use it'. Bullshit, lame excuse. Fire them and hire more competent personnel or send them to a proper training.
It doesn't have to be like this. All we need to do is make sure we keep talking.
Also like windows sloppy coding gives a much wider userbase to exploit as well. Take a long hard look at the code behind Wordpress then get back to us, we'll wait. I'd tell you to do the same for Windows but I suspect you won't be able to pull that one off as easily. Like Windows, Wordpress has pissed off all the good devs and all that's left are the ones that do 'shiny'.
So you have no contact with the software for the past 6 years but you are convinced you know everything about it. Great.
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.
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.