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."
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.
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'.
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.
From what I understand, MySQL truncated the input passed in without throwing any complaints that data was being lost.
That is MySQL's default behaviour. It can be put in strict mode, where truncated fields aren't silently ignored (and various other validity and sanity checks aren't bypassed). Ideally, this would be MySQL's default mode, but WordPress doesn't work in strict mode.
So, I do not think it is as simple as saying it is MySQL's fault. WordPress is complicit in its failure.