I tried to submit the official Wordpress.org announcement and got "stop spamming us".
http://wordpress.org/news/2013/08/oscar/
Is Wordpress.org domain banned on HN?
There are some worthy blogs that could be linked here from wordpress.com, but even if it had to be blacklisted, wordpress.org should not be, there shouldn't be third-party content on it except for maybe the forums.
It's not necessarily about security issues. It's a fairly standard practice across a lot of different software products to not jump on the .0 release of something. For all the testing that gets done prior to release, inevitably some bugs will be shaken out after release.
I've had Wordpress cracked thrice under my watch by automated exploits. That's why I pay Sucuri $400/yr, simply to tell me when it's happened.
The first one used an admin flaw to edit articles directly. The latest used the theme upload capability to write themselves into every theme in the system. (Partly my fault for leaving that directory as writeable by the server). I don't recall what the 2nd one did.
Wordpress bundles security patches and bugfixes with the releases. You can't have them separately.
If you need a fix or security update the basic mechanism is "fuck you, upgrade".
Otherwise I wouldn't have upgraded for the past dozen versions or so.
Basically I have to split the risk between security improvements and data loss.
As you can imagine ... I am not a fan of Wordpress.
There's a well documented and fairly complete export format, and there's even a gem to allow direct import from MySQL -> Jekyll. There are many other blogging services and/or platforms yu could use.
Really don't understand people like you, hating the platform they're on when they have complete freedom to move.
Some of us are stuck due to management decisons (Drupal, for me, currently) - we've had a huge push to switch to Rails, but no go, our network hasen't given official ATO. (Military/DOD)
I've never used WP but I've read about it quite a bit. Usually it'd be after site X on HN goes down for not enabling caching and not being able to handle the load. There's always links to "best practices for caching" or other tidbits. Out of everything I've read though nothing is as funny as wp-cron[1]. If you're not familiar with it then it's worth a read for a good laugh. See [2] for a nice article about it, in the meantime here's a summary:
If you don't have a native cron installation (eg. shared hosting or Windows) you can config WP to act as a cron daemon (actually might be enabled by default). The catch though is since everything is WP is triggered by HTTP requests the way wp-cron works is to check if there is a job to run every time a WP page is hit. Yes you understood that correctly, every single page that is rendered also checks if it should fire off a cron job. The jobs get executed async in the background so it doesn't hold up the ongoing request but it has two interesting properties.
1. If your site gets a large influx in traffic the server runs wp-cron for every page hit and further slows things down.
2. If your site gets no traffic then it doesn't run at all.
It's just a hack for people without access to cron. It was more of problem back in the day when hosting services didn't offer control panels and most wouldn't let you have command-line access. If you knew your hosting company well, you could maybe talk someone into setting up a cron job.
I remember doing something similar for a stats script that would wipe old data every time it was viewed by an admin.
Yes that's exactly why it came about. I still find it very interesting (and humorous) solution though. I've seen the same inner platform effect in legacy systems at large corporations.
It's kludge plain and simple. It's ugly but it works (well kind of). That's the exact definition of a kludge. Further interesting things with wp-cron is that since other plugins make use of it, if you do have a "real" cron implementation the advice is to use the real cron to trigger wp-cron (via curl hitting a localhost only accessible page). Again, it's a kludge but it keeps things running.
On the topic of new stacks from the OS on up, Docker[1] (and lxc in general) and CoreOS[2] are really cool. It's a much more elegant and long term solution to packaged, yet controlled, environments.
Ironically, you could wind up without any where to run your cron jobs in such a setup as well... (eg: running scheduled tasks in the container as the db/cache/webapp uid).
This is of course fixable, but still interesting given the context.
How? Crown is just a process that sleeps for a minute at a time, checks the config file, forks a process if needed and repeats plus some logging. The only reason WP does not implement that is because shared hosting will kill long running processes.
Lol the inspiration must have come from the session gc, except it doesn't hurt if the gc isn't run due to a lack of page requests. On the other hand I guess something is better than nothing. I have had to use servers with real cron to execute scripts on servers without it to get around this.
The glory of this system is that WP retains their stupid easy install.
I suspect they pull down the data for whether a cron needs to be run in an initializing query that also pulls down a ton of other data (site name, for example). So in theory, they're only doing a few time comparisons of extra work per request.
Also - I haven't looked too deep into WP's implementation, but are they actually doing it on page load? I've seen it in other php software (I believe phpBB) as a 1px image. This kinda solves the caching issues others are talking about...your server might still get hung up, and that picture might never load, but if you're cached properly I think it won't stop anyone from reading.
Ignoring the bugs though...I've had my shared hostgator plan handle a couple of top page HN post with no additional caching installed, which makes me think it's probably not a problem for most people running WP. (I just double checked to make sure that's actually true, and it is.)
> I haven't looked too deep into WP's implementation, but are they actually doing it on page load?
On page load (that is, when WP actually runs), WP fires off a non-blocking HTTP request to itself. This runs at maximum once per minute, and shouldn't actually run if you're using Super Cache or similar and hit a cache page.
> So in theory, they're only doing a few time comparisons of extra work per request.
And if a plugin has registered a long-running function, you're kinda screwed.
> Also - I haven't looked too deep into WP's implementation, but are they actually doing it on page load?
Yep.
> I've had my shared hostgator plan handle a couple of top page HN post with no additional caching installed, which makes me think it's probably not a problem for most people running WP.
There's two options that could have been taken here.
1. On hosts that don't support cron, tell users to use an external service to do it, and in the meantime their scheduled posts and other functionality breaks.
2. Implement a workaround like this.
Yes, it's not the greatest solution, but the point is that it works.
In addition, "every single page that is rendered also checks if it should fire off a cron job" is incorrect. A lock is used to avoid running more often than once per minute. If you're at the sort of load where this is an issue, you should be running proper cron anyway.
> > If your site gets no traffic then it doesn't run at all.
>...is a huge problem.
Why?
If you are relying on things to happen at an exact time, them you should know not to use wp-cron. However, for the scope of internal wordpress tasks that don't need to happen every load, I don't see any problem with it happening when wordpress is prodded eventually, and the time it was scheduled to run at has passed.
So ... you dropped by to take a pot-shot at WordPress? Request-based cron imitations have been around for a while particularly for software targeting cheap LAMP hosts (Drupal has an implementation, for instance).
And it only checks if it needs to run a job at page load, it doesn't actually run it everytime, which isn't that big of a deal to check.
Wordpress has a very high focus on readable code which does seem to affect it's speed. But it is easy to use, setup and hack, which is why it is popular. And as Yahoo and wordpress.com clearly shows, it does scale.
If you have a hosting where you can't set a cron (most of the shared hosting I've used has crons though) you can use a free service like https://www.setcronjob.com (not affiliated).
It's easy enough to disable the built in wp-cron and write your own cron that hits the wp-cron file on your own intervals. This is what I've always done on my WP sites. It's a hack, sure, but I too think the wp-cron thing is rediculous.
Shipping caching by default would be a better start. The Wordpress team have said that the hosting implications of writing to disk make it a non-starter; but for some reason that didn't stop them from shipping auto-update or one-click plugin/theme installation in mainline.
The WordPress leads speak from experience. Caching objects to disk was introduced in WordPress 2.0, released in 2005. Turns out it actually slowed down the vast majority of sites.
Databases are really, really good at storing and retrieving data, much more than filesystems, especially when those filesystems are often remotely mounted drives.
The functionality was pulled back out of WordPress in a later version, leaving all of the various hooks needed for a plugin to super-easily implement it on its own. I use a memcached powered one for example.
Firstly, MySQL is actually terrible at the core task of Wordpress, which is joining tables with TEXT fields. If it finds a TEXT field it throws its hands in the air and joins on disk, taking great care to avoid any indexes you might have added to speed up those joins.
Any time the query cache isn't there to save you, you wind up stomping around on disk anyway. Fun fact: the recent comments widget that ships in mainline blows the query cache.
Secondly, file caching could still ship in mainline with a tickbox to enable it.
Thirdly, I've never seen a site that wasn't improved by file caching. However I believe you that the Wordpress guys get a lot more reports than I do.
This is exactly what plugins are for. Most people aren't going to need this, and for those that do, there's a tonne of plugins out there that will add this functionality for you.
I have to admit I'm surprised a community like HN would upvote such a vulnerable package. Hell, even our sites that have been converted to static HTML still receive requests for /wp-admin/ by bots all the time.
Thanks for allowing non-technies to set up their own site but no thanks--I'm good.
I also find it interesting that you as a core dev narrow down possible answers by using "serious" and "lately" in your question. Of course you specifically ask for "WordPress exploits" as well, maybe because themes and plugins run with the same privileges as WordPress core code, and there's no review process for official plugins hosted on wordpress.org? Not to mention from other sources..
To clarify: I'm not part of the core team, I'm just a contributor. (I've also only briefly looked at this issue.) Keep in mind that while I'm an active contributor, I don't speak on behalf of the core/security teams.
The aforementioned bug is in the phpass library used in WordPress. As fun as implementing our own cryptography is, we use the phpass library to abstract ourselves from this. Personally, I'd say this is something that phpass should be handling, as the use of crypt_private() is an implementation detail that we shouldn't need to know or worry about.
(This is also an issue that affects a small portion of sites, as "Exploitation of this vulnerability is possible only when there is at least one password protected post on the blog.")
As to the response from the security team (which is not exactly the core team), that's something I've called them out on before. Security is a serious issue that is usually handled very well on WP's behalf, but there have been a few notable instances lately where it's not.
(Also, the reason I "narrow down" the answers is because there are smaller "security" issues that tend to boil down to "admins can do anything", which is intentional.)
I hate Wordpress as much as the next fellow, but I'm wary of blaming them for architectural constraints they can't control.
Plugins run in the same process, with the same privileges, because there is basically no other way to do it.
OK, sure, you can do a kind of kabuki theatre where you present an API and insist plugin authors use it. But then they can access everything anyway and can find the MySQL login details by introspection. So it's pointless.
Another reason why I think apps should target virtual machines and be designed from the OS up. In such a design you can isolate plugins as standalone users and standalone processes.
Plugins can only access "everything" because of the complete lack of architecture or design. Wordpress is a series of ill thought out hacks, extended by other hacks, extended by yet more hacks.
Every time one of our WP developers asks me to help with something (usually they assume its a server config issue) I'm astounded at the shit I find when I discover the source of the problem.
Like I said, I don't like Wordpress either. But within the constraints of shared hosting LAMP, guaranteed isolated processes are not possible. PHP adds a lot of introspection, so anything declared anywhere can be read or changed.
Wordpress is not alone in this. It's the platform.
We're still talking about different things. Yes, WP could be better. This is demonstrable from other, better-designed engines within the LAMP/shared constraints.
But no such system can prevent any plugins from doing whatever they want to do.
Introspection & Reflection in PHP don't expose everything, and frankly even if they did, it would be quite easy to analyse plugins and have an approved list of "safe" plugins that is used either as an advisory or as a basis for the available plugins shown to a user.
Themes being PHP code or plugins being hosted on wordpress.org without any code review isn't beyond anybody's control. Of course the former will never be fixed, there is no deprecation policy.
But yeah, if you have to host such software virtualization and isolation is a good idea.
HN users often view PHP and those products built using PHP with disrespect. Sure they have their problems, but these products have been around for an eternity (in internet terms). Lots of programmers wouldn't have long standing careers without them.
FWIW, I just tried to update my dev site, the install failed, and now the site fails to load. Yikes.
In all fairness, I think that's because the admin has been playing around with file permissions on the server side. I can't even log in right now to read the errlog.
65 comments
[ 2.9 ms ] story [ 106 ms ] threadMaybe some wordpress.com blogs were being used for spam but wordpress.com != wordpress.org
wordpress.com is the blog hosting site
There are some worthy blogs that could be linked here from wordpress.com, but even if it had to be blacklisted, wordpress.org should not be, there shouldn't be third-party content on it except for maybe the forums.
Just curious whether or not your fear is from a previous experience.
Will you upgrade to new releases day 1 when WordPress implements auto-updating on the security updates?
Yes, I have backups. It pisses me off having to use them.
The first one used an admin flaw to edit articles directly. The latest used the theme upload capability to write themselves into every theme in the system. (Partly my fault for leaving that directory as writeable by the server). I don't recall what the 2nd one did.
Wordpress bundles security patches and bugfixes with the releases. You can't have them separately.
If you need a fix or security update the basic mechanism is "fuck you, upgrade".
Otherwise I wouldn't have upgraded for the past dozen versions or so.
Basically I have to split the risk between security improvements and data loss.
As you can imagine ... I am not a fan of Wordpress.
There's a well documented and fairly complete export format, and there's even a gem to allow direct import from MySQL -> Jekyll. There are many other blogging services and/or platforms yu could use.
Really don't understand people like you, hating the platform they're on when they have complete freedom to move.
http://ozblogistan.com.au/
I am not all of these people.
Come on, that's hardly an epic migration. Why would you let them blog on a platform you hate and that you consider insecure.
If you don't have a native cron installation (eg. shared hosting or Windows) you can config WP to act as a cron daemon (actually might be enabled by default). The catch though is since everything is WP is triggered by HTTP requests the way wp-cron works is to check if there is a job to run every time a WP page is hit. Yes you understood that correctly, every single page that is rendered also checks if it should fire off a cron job. The jobs get executed async in the background so it doesn't hold up the ongoing request but it has two interesting properties.
1. If your site gets a large influx in traffic the server runs wp-cron for every page hit and further slows things down.
2. If your site gets no traffic then it doesn't run at all.
Funny eh?
[1]: http://core.trac.wordpress.org/browser/tags/3.6/wp-cron.php
[2]: http://wp.tutsplus.com/articles/insights-into-wp-cron-an-int...
I remember doing something similar for a stats script that would wipe old data every time it was viewed by an admin.
Essentially, given the constraints of the LAMP architecture, wp-cron is the only way to do it.
You overlooked that wrapping WP in layers of caching restricts wp-cron's supply of triggering events. It's a mess.
Especially since LAMP is not the universal web app target any more. We can and should architect from the OS up.
On the topic of new stacks from the OS on up, Docker[1] (and lxc in general) and CoreOS[2] are really cool. It's a much more elegant and long term solution to packaged, yet controlled, environments.
[1]: http://www.docker.io/
[2]: http://coreos.com/
This is of course fixable, but still interesting given the context.
I suspect they pull down the data for whether a cron needs to be run in an initializing query that also pulls down a ton of other data (site name, for example). So in theory, they're only doing a few time comparisons of extra work per request.
Also - I haven't looked too deep into WP's implementation, but are they actually doing it on page load? I've seen it in other php software (I believe phpBB) as a 1px image. This kinda solves the caching issues others are talking about...your server might still get hung up, and that picture might never load, but if you're cached properly I think it won't stop anyone from reading.
Ignoring the bugs though...I've had my shared hostgator plan handle a couple of top page HN post with no additional caching installed, which makes me think it's probably not a problem for most people running WP. (I just double checked to make sure that's actually true, and it is.)
On page load (that is, when WP actually runs), WP fires off a non-blocking HTTP request to itself. This runs at maximum once per minute, and shouldn't actually run if you're using Super Cache or similar and hit a cache page.
And if a plugin has registered a long-running function, you're kinda screwed.
> Also - I haven't looked too deep into WP's implementation, but are they actually doing it on page load?
Yep.
> I've had my shared hostgator plan handle a couple of top page HN post with no additional caching installed, which makes me think it's probably not a problem for most people running WP.
HostGator install WP Supercache by default.
1. On hosts that don't support cron, tell users to use an external service to do it, and in the meantime their scheduled posts and other functionality breaks.
2. Implement a workaround like this.
Yes, it's not the greatest solution, but the point is that it works.
In addition, "every single page that is rendered also checks if it should fire off a cron job" is incorrect. A lock is used to avoid running more often than once per minute. If you're at the sort of load where this is an issue, you should be running proper cron anyway.
> If your site gets a large influx in traffic the server runs wp-cron for every page hit and further slows things down.
Which involves a single database hit and a `foreach` loop. Or, if you're using an external object cache (memcached, APC, etc), no DB hits.
Probably not as dire a situation as it seems. This...
> If your site gets no traffic then it doesn't run at all.
...is a huge problem.
>...is a huge problem.
Why?
If you are relying on things to happen at an exact time, them you should know not to use wp-cron. However, for the scope of internal wordpress tasks that don't need to happen every load, I don't see any problem with it happening when wordpress is prodded eventually, and the time it was scheduled to run at has passed.
And it only checks if it needs to run a job at page load, it doesn't actually run it everytime, which isn't that big of a deal to check.
Wordpress has a very high focus on readable code which does seem to affect it's speed. But it is easy to use, setup and hack, which is why it is popular. And as Yahoo and wordpress.com clearly shows, it does scale.
Databases are really, really good at storing and retrieving data, much more than filesystems, especially when those filesystems are often remotely mounted drives.
The functionality was pulled back out of WordPress in a later version, leaving all of the various hooks needed for a plugin to super-easily implement it on its own. I use a memcached powered one for example.
Any time the query cache isn't there to save you, you wind up stomping around on disk anyway. Fun fact: the recent comments widget that ships in mainline blows the query cache.
Secondly, file caching could still ship in mainline with a tickbox to enable it.
Thirdly, I've never seen a site that wasn't improved by file caching. However I believe you that the Wordpress guys get a lot more reports than I do.
Finally, 2005 was eight years ago.
Thanks for allowing non-technies to set up their own site but no thanks--I'm good.
If there's a request for cgi-bin should we throw apache away, too?
I also find it interesting that you as a core dev narrow down possible answers by using "serious" and "lately" in your question. Of course you specifically ask for "WordPress exploits" as well, maybe because themes and plugins run with the same privileges as WordPress core code, and there's no review process for official plugins hosted on wordpress.org? Not to mention from other sources..
The aforementioned bug is in the phpass library used in WordPress. As fun as implementing our own cryptography is, we use the phpass library to abstract ourselves from this. Personally, I'd say this is something that phpass should be handling, as the use of crypt_private() is an implementation detail that we shouldn't need to know or worry about.
(This is also an issue that affects a small portion of sites, as "Exploitation of this vulnerability is possible only when there is at least one password protected post on the blog.")
As to the response from the security team (which is not exactly the core team), that's something I've called them out on before. Security is a serious issue that is usually handled very well on WP's behalf, but there have been a few notable instances lately where it's not.
(Also, the reason I "narrow down" the answers is because there are smaller "security" issues that tend to boil down to "admins can do anything", which is intentional.)
Wp is/was using the library wrong
Plugins run in the same process, with the same privileges, because there is basically no other way to do it.
OK, sure, you can do a kind of kabuki theatre where you present an API and insist plugin authors use it. But then they can access everything anyway and can find the MySQL login details by introspection. So it's pointless.
Another reason why I think apps should target virtual machines and be designed from the OS up. In such a design you can isolate plugins as standalone users and standalone processes.
Every time one of our WP developers asks me to help with something (usually they assume its a server config issue) I'm astounded at the shit I find when I discover the source of the problem.
Wordpress is not alone in this. It's the platform.
But no such system can prevent any plugins from doing whatever they want to do.
But yeah, if you have to host such software virtualization and isolation is a good idea.
In all fairness, I think that's because the admin has been playing around with file permissions on the server side. I can't even log in right now to read the errlog.
http://wordpress.org/news/2013/08/oscar/