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.
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.
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.