New Zero Day Disclosed In WordPress Core Engine 89
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: (Score:1)
Re: (Score:1)
Fortunately, many 1960s era mainframes had (and still have) BOFHs guarding them.
Victim of liberal error handling (Score:4, Insightful)
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).
I say it's the fault of the NEOCONs (Score:1, Funny)
Whenever I see people accusing the Liberals for anything I get angry, very angry
It is the fault of the NEOCONs all the while
If not because of the goddamn NEOCONs everybody would have been using postgresql rather than that piece of turd mysql
Re: (Score:2)
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 think this speaks clearly of how bad was the decision of creating HTML 5, and not making future web documents an XML application only. With XML, the rules clearly state that a document has to be well formed in order to be interpreted by the XML parser (then it can be invalid according to the XML application, say XHTML). But no, they kept the incredibly stupid tradition of making browsers try to recover according to unspecified ways. I wonder how many workarounds are in the parsers of todays web browsers t
Re: (Score:2)
Re: (Score:1)
It did take off; many people wrote XHTML documents, and it's default in e.g. Drupal. The problem was IE didn't support application/xhtml+xml until recently, which is exactly what gave XHTML all its functionality.
Re:Victim of liberal error handling (Score:5, Interesting)
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.
Already patched (Score:3)
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:Already patched (Score:5, Insightful)
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'.
Re: (Score:2)
Re: (Score:2)
So, that left your website vulnerable for a few hours... again!
And being a prime target wouldn't be a problem if it had proper security...
Re: (Score:2)
And being a prime target wouldn't be a problem if it had proper security...
Oh how naive.
Re: (Score:1)
And being a prime target wouldn't be a problem if it had proper security...
Oh how naive.
Will you please enlighten the unwashed masses (me), how a system with proper security would not pose a problem like the one underlying this topic?
(And please, without resorting to 'shiny', 'easy', 'simple', 'extensible'. I am honestly only interested in security.)
Re: (Score:2)
"And please, without resorting to 'shiny', 'easy', 'simple', 'extensible'. I am honestly only interested in security."
No, you aren't.
Because if you really were only interested in security, you would just turn off your computer and done with it. No, you are not *only* interested in security, and there is where those 'shiny', 'easy', 'simple', 'extensible' concepts go into the equation. Security means balance.
Re: (Score:2)
The issue described in this topic (cross-site scripting) is very old (about 15 years in this case). But so is its solution. The same goes for all other security issues. There is no reason and therefor no excuse to have such or any other known vulnerability in your website today. Specially because the solutions are very easy. Security is no rocket science!
The majority of all hack attempts are for SQL injection, cross-site scripting, cross-site request forgery, remote file inclusion, directory traversal, etc.
Re: (Score:2)
That's like 90% of all developers :D.
Re: (Score:2)
Hardly. You weren't interested in security at all. You were talking about being a prime target and being a prime target is something that comes from popularity and the potential for a single exploit to affect the largest number of people in one go.
If you had a theoretically perfectly secure piece of software that every single person in the world uses in the same way you will still be no less of a prime target with hackers queueing up long lines to try and break something. Kind of like how people will still
Re: (Score:3)
It only applies security updates automatically if the user the PHP scripts run as has write access to the WordPress directory. I never allow that. I'd rather have the security of knowing a WordPress exploit can't modify the WordPress installation than the convenience of updates through the web UI.
This latest exploit also depends on a logged in administrator viewing the malicious comments to do the really nasty stuff. This is another very good reason to only ever log in as an administrator when you absolu
wait, what? (Score:1)
Server side code execution?
I'm sure they mean client side, since I doubt word press is parsing and executing JavaScript on the server.
Re:wait, what? (Score:5, Informative)
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.
Re: wait, what? (Score:4, Insightful)
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.
Re: (Score:3, Informative)
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 an
Re: (Score:2)
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.
Sure, but that's a necessary feature of any self-updating CMS. And if you're hosting it, you usually only have one username anyway, so the files can't be owned by another user.
Re: (Score:2)
Those who are more paranoid acknowledge that ownership problem and do updates using an alternate method, i.e. login.
I don't think you understand what I said. If you've only got one uid, then both your web user and your shell user are the same user. This is typical of low-cost hosting services. Unless you're colocating, you've typically only got one uid. This ain't the law, some providers will let you crank them out, especially if you're chroot'd.
Re: (Score:2)
And all this can be prevented if administrators simply adding one line to their wp-config.php
If you read TFA, you would know that your comment tends to illustrate that you are on the high horse. Your statement is similar to "what should have been done," but that is not the point. The point is that the exploitation is still alive and people should be aware of. If they need to prevent the exploitation, then they could do it in many ways which may include what you 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 the best solution until a patch is made available is to disable comments and not approve any.
Re: (Score:2)
Wordpress provides a large amount of hardening functions like this
...which are completely freaking worthless if they're turned off by default. 99.9% of users will never visit and study every available config option, and the other .1% will be wondering why it's not the default setting if it's so great.
Your post is like those who insist that MySQL has safe data settings for those who know how to enable them, while ignoring the fact that almost everyone uses the configuration as shipped. Unsafe by default is an insane and undefensible way to distribute software. In fact, I c
Re: (Score:1)
And all this can be prevented if administrators simply adding one line to their wp-config.php
define('DISALLOW_FILE_EDIT', true);
Why the fuck isn't that the default? If an "administrator" needs this functionality, they should have to intentionally turn it on. Having all of these whiz-bang cool features turned on by default is half the problem. Most people who install Wordpress onto their GoDaddy account and head off to the races aren't "administrators," and don't need to have this stuff exposed.
And still we don't learn (Score:2, Insightful)
Re: (Score:3)
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 P
Re: (Score:3)
Re: (Score:2)
This is all true, but people are more likely to go with what's available (generally meaning pre-made themes) or what developers work on most often (meaning the major platforms). Finding hosting that offers alternatives to PHP may also not be the easiest thing, especially if you don't know about PHP's history.
None of this is insurmountable with knowledge and/or research, but it's a larger hill than that of PHP, so the tendency will be for people to go the easier route.
Re: (Score:2)
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.
Haven't tried Drupal eh? Damning with faint praise, but it's notably better than WordPress. The only PITA is dealing with database access, but so far I've been able to do that through other modules' code and haven't had to do it directly.
Re: (Score:2)
I tinkered with Drupal, but the philosophy behind Joomla to abstract as much of the code as possible was appealing, and this was right after the SQL injection vulnerability discovered in October, so my trust of their code was lacking. Maybe Drupal would be better than Joomla on a daily basis, but at the time, it just had too much going against it.
Re: (Score:2)
I haven't messed with Joomla much so I can't speak as to which is better, but I'm pretty clear that Drupal is at least slightly better and less of a headache than is Wordpress.
Re: (Score:2)
WordPress is trivially easy to use. That's it's draw. Just figuring how to edit a menu in Joomla took significant effort, and I still have to refer back to my notes to figure out how to do it if it's been a few weeks and I need to create something from scratch. It's significant overkill for someone who just wants to set something up to get their words out to the world.
There are other issues that can be a headache as well. A lot of people rely on auto-installers to get things in place, but Joomla's web i
Re: (Score:2)
Re: (Score:1)
Microsoft Frontpage
Re: (Score:2)
This looks like a non-answer, then. Since Banshee is a framework, not a CMS.
Re: (Score:2)
And before you come up with "but my Wordpress websites also have never been hacked", I meant: hack-free without any update or me having to worry about its security.
Re: (Score:2)
Re: (Score:2)
When will people start looking beyond a nice and shiny interface and put quality (which includes security) at the top of their priority list.
As soon as another easy to use, easy to implement system comes along that can replace it. Next you'll be complaining we don't all program by tapping the 1 and 0 button on the keyboard in a certain pattern.
Abstraction has it's place, and there's essentially no alternative to wordpress that has the feature set, documentation, ease of use, and user group behind it.
Re: (Score:1)
Get off your high horse. People no longer use shared website hosting with manually crafted pages using "web developers", they use GUI driven commercial websites that use various packages instead. Don't blame the user for trusting professional services, blame the shitty programmers that don't write secure applications. I wonder why you're so defensive.
Re: (Score:3)
Re: (Score:1)
Sounds like you're re-inventing the wheel there.
Re: (Score:2)
There are solutions that almost do what we need but those are all offered as services and it's not easily possible to integrate the rest of what we want with them. Plus, they're technically our
Re: (Score:3)
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
Re: (Score:1)
I don't think you arguments are valid. There is much more between a free Wordpress website and a custom coded CMS + all the extra's. You know this. And sure you can setup a website in 20 minutes for free. But if that's the price you want to pay, than that's the quality you get. And btw, I also can setup a website within 20 minutes for free, but with a CMS that even the most skilled hacker will have a hard time with to hack.
Re: (Score:2)
Which one are you talking about? I'm seriously interested in exploring other options!!
Thanks!!
Re: (Score:2)
Re: (Score:2)
Ummm... I suspect that Wordpress administration does not work or at least does not work well with Javascript disabled.
Word Press? Wow! (Score:1)
I used to offer WordPress as blog engine to my users. Like .... 7 or 8 years ago. And half of my time was spent updating, upgrading, and cleaning up after WordPress. After close to 1 year I had withdrawn this offer.
Is there no way to simply prohibit this piece of malware-spouting horribly bad architectured s**tware that seems to have been lingering about ever since?
Re: (Score:2, Insightful)
So you have no contact with the software for the past 6 years but you are convinced you know everything about it. Great.
Re: (Score:2, Informative)
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 se
Re: (Score:2)
so because wordpress core is installed on so many servers, that's why the code magically did not have a length/content check on it?
what logic is that? shouldn't it be the other way around.
Re: (Score:1)
He's saying that shit happens, and any other product you use or write yourself is going to have some vulnerability in it that just may not be discovered because nobody cares to look. WordPress runs something like 19% of all internet sites. And yet, how often do you hear about WordPress core (not plugin) vulnerabilities? The last I can remember before this one was a handful of them in 2009.
I'd honestly have to say that core WordPress is one of the most secure pieces of non-trivial software in existence to
Re: (Score:2)
Re: (Score:2)
It isn't as bad as it used to be. There are far fewer security issues found these days, and they don't tend to botch major releases the way they used to. However it's succumbing to bloat, each release bigger than the last.
Re: (Score:2)
"I used to offer WordPress as blog engine to my users. Like .... 7 or 8 years ago. And half of my time was spent updating, upgrading, and cleaning up after WordPress."
Well there's your problem. WordPress 4.2.1 of 2015 is a totally different system than what you were using. It is now much easier to update, upgrade, clean and manage. Try it again.
My Wordpress is 4.2.2 (Score:2)
WordPress XSS cross-site scripting vulnerability . (Score:2)
"Zero day"? (Score:5, Insightful)
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.
New Zero Day Discovered In WordPress Core Spagetti (Score:2)
New Zero Day Discovered In WordPress Core Spagetti.
FTFY.
(Note: I currently make a living developing/deploying with WordPress)
discovered in the WordPress 4.2 (Score:3)
"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.
Reporting bugs to them is useless (Score:2)
Reported a zero day used to attack my site two weeks ago. Attached tcpdump of attack.
Have not heard back. Not even a simple "We've received your report and will get around to it whenever".
Shachar