Hacker News Reader

Comment by jakarta | Hacker News Reader

So let's get this straight:

He's complaining about Wordpress and their vulnerabilities when he:

1. hadn't upgraded wordpress in months 2. hadn't performed any backups of his posts

It's hard to be sympathetic to him or TechCrunch. If they're going to use custom features like third-party plugins and specially designed pages, they should have developers on staff to actively work to make sure that their customizations will work after an upgrade. By not doing that they're begging to be attacked.

View on HN

Seeing as WordPress requires security updates with genuinely astounding regularity, I'm hesitant to blame the user. WordPress' excessive vulnerability count clearly demonstrates an endemic issue in the software itself.

or... another way to look at it. Wordpress releases security updates at astounding frequency without waiting to lump all those security updates in to one large update like most other large software tends to do.

Yes, I admit frequent updates can be a nuisance, but when they are literally spoon feeding you the update process (less than 10 seconds and one click in most cases), its stupidity - really.

Drupal CMS less popular - more vulnerability.

In fact, I wish they had an HTTP callback API so I could just give them push access to update my server automatically. (IE: wordpress blogs have a URI that wordpress.org would post the new version to, when available.) Of course, this would all need to be signed.

Is there any other CMS that do that? That would be a nice way to update. I remember reading somewhere a guy had a script that checks for new version everyday and upgrades automatically.

For me, I am subscribed to their blog so get notified by e-mail when there is an upgrade, from there it takes less than a minutes to login to my admin and upgrade. As a matter of fact, I did my last update from my iphone when I was on the road.

It doesn't even need to be that complicated. A Wordpress install is already capable of checking for new versions and updating itself. All that's needed is for this to be checked and performed at various intervals using a wp-cron style scheduler (e.g triggered by user visits).

It's an artifact of their development practices and code quality that requires such frequent updates, not a desire to provide regular small patch sets.

See tptacek's comment on their implementation quality: http://news.ycombinator.com/item?id=806910

You can also compare the quantity and severity of vulnerabilities against MediaWiki:

http://www.securityfocus.com/cgi-bin/index.cgi?o=0&l=30&...

without waiting to lump all those security updates in to one large update

Why do there have to be frequent security updates in first place?

If they didn't manage to tighten up their very limited attack surface in 6 years then I'd say it's a lost cause.

For a widely popular software like wordpress, security will be a cat and mouse game - until it reaches a level of maturity like other open source projects (ie, linux).

For me the problem is not that they release frequent updates - I would have a problem if they didn't release frequent updates to known severe vulnerabilities. If you look at their release logs you will see that most of their security updates has 24-48 hours of turnaround from the time of the vulnerability detection.

The recent vulnerability that this blog and most others (ie, smashing magazine) got affected has been fixed 2 releases before the current release. People who are affected didn't update for the last 3 release and someone developed a script out there that automatically scans for that vuln. and takes advantage of it.

I'd argue that the frequency of security updates points to a fairly immature security architecture - it might be ages before they get anywhere near other sufficiently secure open source projects (although comparing it with linux is a bit like comparing apples and bananas).

security will be a cat and mouse game

From a security standpoint Wordpress is a trivial application because it's almost entirely read-only, except for the comments. Making a plugin-architecture bullet proof is a different story, but as I understand it most of these issues affect the very core, i.e. a vanilla wordpress install.

There is no excuse for their sorry state of affairs.

It's been an interesting 6 years. Many attacks we protect against now (XSRF, most types of XSS) were basically unknown then. Some (cryptographic splicing) were popularized by researchers auditing WordPress. A mixed blessing of being popular is that everyone is looking at your code. However we try to turn around fixes as quickly as humanly possible, and with few exceptions (Scoble not upgrading) high profile WordPress blogs (CNN, NY Times) have never had any security problems.

For what it's worth, Drupal is only more vulnerable if you install third-party modules that are vulnerable and don't update those, as well. If you happen to be interested (which I hope you are, since you brought up the subject of Drupal security), see http://www.lullabot.com/node/383 for a thoughtful take on the open security model.

Your comparison to Drupal is invalid.

That list lumps in security vulnerabilities from over 4000 third-party plug-ins.

I browsed 3 pages .90% of them are related to external modules. Whereas about wordpress, well no comment. It is not about which one has more vulnerability it is about design and how the software enforces security. Take a look at drupal prepare query callback http://api.drupal.org/api/function/_db_query_callback/6 with respect to WP's prepare function in wp-db.php(I have WP version 2.7.1). Drupal's code is double checking users data on the other hand WP just unquotes the %s section. Also look at escape function of the same file. It uses addslashes and commented out mysql_real_escape_string function because it is causing problems!! WTF. Also drupal has a very good guidline on writing secure drupal modules http://drupal.org/writing-secure-code. Show me a equivalent in WP. So your popularity proportional to vulnerability theory is mostly flawed.

In many ways the extremely high frequency of Wordpress security updates completely works against them.

Whenever a security update is released it is utterly trivial to do a diff against the previous package and get a vector to exploitable vulnerabilities in the previous version (in many cases the changelogs themselves are a good hint). The default Wordpress headers also make it easy to quickly tell which version of WP a site is running and whether it's worth attacking.

I give Wordpress credit for the advances they've made in automating parts of the upgrade process - it's now one click from the dashboard and if you are a popular site there really is no excuse for running an out of date version.

However it's not enough. Wordpress need to move to minor/major versions where minor versions, that consist of security updates, are automatically updated to when detected by a blog. (Major updates that feature changes likely to break plugins should still require user input).

Before we can auto-upgrade people we need to figure out how to do so in a way that's fool-proof. Can you imagine the outrage if everyone woke up one morning to broken sites because of an auto-applied update?

I agree. But imagine the outrage when your schema is wiped out. How about a wordpress release which can automatically "disable" the feature/page/plugin/script that express the vulnerability? And throw in an SMS page when an update happens so it wakes them up right away instead of waiting for them to discover it in the morning.

WordPress developers don't issue security upgrades, they only release new versions, which break compatibility. This is why users don't update.

Reply on news.ycombinator.com