WordPress ought to issue deprecation notices, really

Agreed. I think that at a certain point, wordpress needs to come up with a simple way to make it so that ancient and unsupported plugins and themes cannot be used or at least cannot be EASILY used on current installations.

I agree, there should be warnings on the admin panel when plugins are getting old. I also think that wordpress should work to try to keep in contact with developers and ask them to update their plugins from time to time, at least to confirm that they are “live” and maintained. Plugins that don’t get checked by the authors should be marked as “not maintained”, which would discourage the use of plugins that might cause future issues.

I’m sure I’ll regret this, but how does any of this address security? ??

I’m not asking about security theory, I am asking for a specific example where old code == insecure.

Note: old code is not insecure. Some code is determined to be exploitable, new and old code alike. How does the effort described above do anything to address valid security concerns?

Hello Jan,

You’re making me realize I was not afraid of the right thing, so thank you, and I’ll express differently what was causing me to worry:

The issue isn’t actually that code is old, the issue is that a plugin that wasn’t updated once in several years is most likely abandoned, and thus we have no way to tell if it wouldn’t contain exploitable elements.

I may be mistaken in writing this (no, honestly, that’s not a manner of speech, it’s an opinion that I can’t base on facts), but I think that since WordPress is an extremely lively ecosystem, while it is technically possible for a non-abandoned plugin to stay static for years, a multi-yearly lack of any update without meaning the plugin author abandoned his plugin, that would be most improbable.

And relying on abandoned plugins means a high risk.

Conversation is good and this is the right place to discuss feedback.

The issue isn’t actually that code is old, the issue is that a plugin that wasn’t updated once in several years is most likely abandoned, and thus we have no way to tell if it wouldn’t contain exploitable elements.

I’ve added emphasis to your quote. ??

The thing is, we really do. It’s called code review and it’s something that is done by people all the time. Often just as an exercise. It’s not the easiest thing to do but it is doable and has nothing to do with old or abandoned code. Code can be audited and some people do that for a living (not me, thank goodness!)

What I’m trying to articulate is that you appear to be focusing on the old/abandoned aspect of code. This current alert from Sucuri shows that you can discount the old code; new and maintained code is just as likely to be exploitable.

https://blog.sucuri.net/2015/04/security-advisory-xss-vulnerability-affecting-multiple-wordpress-plugins.html

The list of plugins there are all current and maintained. There’s not one plugin on that list that is not actively developed.

When you visit an old plugin on the WordPress repo, you get a warning that it’s not been updated in years. Here’s my favorite example.

https://www.ads-software.com/plugins/limit-login-attempts/

This plugin hasn’t been updated in over 2 years. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.

That plugin will not come up on your own WordPress dashboard. The dashboard will only show search hits for current plugins that are maintained. That does address your concern with plugins but that doesn’t do that for security concerns. It does it for potential compatibility issues.

That plugin is not insecure by any stretch. I’ve used it and recommend it as a solution because it works. But there are newer plugins that may do a better job of that. I’ve now switched to Jetpacks Brute Protect feature because the mass data collection portion appeals to me.

I think it’s important to also distinguish between old and abandoned, just because a plugin hasn’t been updated doesn’t mean it no longer functions or is abandoned, it could mean it doesn’t need updating.

As more and more devs switch to the philosophy of a single plugin for a single function, you are going to find lots of very small, few lines of codes that do the job today and will continue doing them in ten years time if you let them.

Are these becoming less secure as they age? while possible it’s unlikely.

Indeed an argument could be said that older, stable battle tested reviewed code that doesn’t get constant updates and changes is a good thing.

There is an argument that historically code reviews before plugins were approved on w.org were sketchy at best, thats no longer the case and every plugin is reviewed initially however the changes are not. So you could draw a line and say anything pre 2010 is a wee bit suspect.

But remembering on the first update which could change 100% of code is not reviewed before pushed the argument older a plugin less secure doesn’t hold much weight, as the more recent the plugin update the less eyes will have been passed over it, the more likely you could argue a security hole will develop.

This is especially true as plugin features increase as does the codebase. So something that entered the repo as a small little thing of a few hundred lines of code. Can easily spawn thousands of lines of unreviewed code just one iteration later.

So within the repo, you are looking for small plugin, with limited codebase, which has never had an update and has been approved in the last couple of years. Even then you are relying on a human and some automated tests spotting issues.

If we applied that ruleset and flagged everything else, we would have a pretty robust secure(ish) set of plugins and an awful lot of angry folks wanting all the features of the thousands of other plugins.

… woah, I learnt a lot, here.

Well, then, thank you very much for the replies, and I guess my original statement was wrong, then, age means little to security, at least in the present case.
Point taken, sorry to have sparked the wrong fire ??

Code review is important, but by it’s nature, code review could also be part of a solution to tell the difference between dead code and old code that still does the job. Right now, there is no simple way to tell.

The issue of the genericons (and others in the past) are particularly important in an older code base. How many of the themes currently on www.ads-software.com for download might have this code in it? Based on what I see in server logs, there is plenty of bad stuff out there, and the script kiddies are out there hammering away at it. From my current experience, more than 20% of the current spam and attacks on wordpress sites now comes from other compromised wordpress installs.

At some point, there needs to be a better way to tell good from bad without having to just take your chances.

The issue of the genericons (and others in the past) are particularly important in an older code base. How many of the themes currently on www.ads-software.com for download might have this code in it?

Zero. We scanned the directory and updated all the themes we could find. We found a few extras this morning and patched them too. We are proactive when it comes to security issues around here.

At some point, there needs to be a better way to tell good from bad without having to just take your chances.

That is a good point, and I agree with it. However, to a certain extent, you’re also talking about the problem of policing free, open-source, code. Everything available here is free. All those plugins and themes, free. And the code for them, all freely licensed (using the GPL). All the people that work on this site: volunteers. Sure, some get paid for their efforts by their various companies, but quite a lot of them do not.

So our efforts in this respect have largely been focused at providing enough feedback to allow users to make meaningful decisions. Like the ratings and review system. Like the broken/works voting meter on plugins screens. Like surfacing changelogs for plugins (we’re working on this for themes too). Developer email systems and integration with the support forums. The huge Theme Review Team. Heck, pretty soon, we’re going to tie the translation systems into plugins and themes to let every single one of them get the whole multi-language treatment.

All of these, every one, are ultimately user-driven. The data comes from people volunteering it. Because almost nobody’s getting paid to do this. We’re not the Apple Store. We don’t have a billion dollars of backing. Automated testing only gets you so far, and code review only works when you have enough eyeballs to go around.

Right now, the data is there for people to make meaningful decisions about what packages they use, and the mechanisms are in place for people to leave meaningful feedback on those packages. In two years, there have been 161,227 reviews. Author names are linked to their history on profiles.www.ads-software.com, and you can see what they’ve done and how involved they are in the community. You can see their social links. We give all the information we can to help people make decisions. But ultimately, we can’t force people to make good ones.

We scanned the directory and updated all the themes we could find. We found a few extras this morning and patched them too. We are proactive when it comes to security issues around here.

Thank you for all you are doing ??

I’m reacting to your quote. The idea of having themes patched against old stuff that has become exploitable, that reminds me of the issue of child themes, since we’re creating copies of the theme’s php files that will be (a) used but not (b) updated with the rest of the theme.
I’m not submitting this as a rant, nor as a complaint, more like a constructive criticism, it would be really sweet to see, somewhere, a page on www.ads-software.com with “here is the history of what we searched and replaced for security reasons in the theme repository, take a look if you want to check your own child themes about it” – I imagine it could even be “plugunified” to have the culprit strings searched inside one’s blog.

In this case, the only change to them was to remove the example.html file. Unlikely that a child theme has it. In any case, the WordPress core upgrade yesterday has a routine that goes through looking for that particular file in all themes and plugins, and then it deletes it.

” In any case, the WordPress core upgrade yesterday has a routine that goes through looking for that particular file in all themes and plugins, and then it deletes it.”

Would that be on all upgrades, or only those using the automatic upgrades?

If you run the DB upgrade routine, it runs that same code whether you do it automatically or not.

So, all.

Otto, only “ALL” for the code that you have added in this particular case.

Did update get rid of all the extra stuff in Yoasts plug ins?

Another Guy: You know, the code is open source. You can look at it yourself and see exactly what it does.

For the genericons problem, it searches the entire wp-content directory for any file named example.html, which also contains <title>Genericons</title>, and deletes it.

I don’t know what you’re talking about with regards to Yoast’s plugins. Nor is that really relevant, as Yoast’s plugins are not part of the WordPress core.

“I don’t know what you’re talking about with regards to Yoast’s plugins. Nor is that really relevant, as Yoast’s plugins are not part of the WordPress core.”

Alas, this is the problem. For end users, WordPress is a “thing”. They may not see the shades of grey different between core and plugins or themes, especially considering that plugins like Akismet (and hello dolly, woo hoo!) are part of the core, and themse such as twenty twelve and such are distributed as part of the core updates. Moreover, some of the most popular plugins (like Jetpack) are “in house” products. So as an example, as you dismiss the Yoast issue, your code code has been cleaning up in themes and plugins. Without reading the code, how would a site operator really know?

My take is generally simple, I assume that none of it gets fixed, and I make sure I fix it myself (a couple of hundred times per update… ). So things like questionable sliders, random upload code, and the like all has to be removed to avoid opening security holes. As there is no way to be certain that a plug in or a theme will delete unused files, the only way to handle them properly at this point is full delete and re-install.

A significant amount of the security issues with WordPress are not in core, but in how plugins work and the code they bring to the table. For the moment, there is no simple way to know if a theme or plug in, even downloaded from WordPress site itself, is safe or tested. The security risks of those products reflect on the whole of wordpress as well.

WordPress has an updater for core – yet updating themes and plug ins is basically copy over and that’s it. No way to know if all the files were fixed, no way to assure that old files were removed, and so on.

Yes, I know… it’s not core. it also doesn’t help make wordpress look very secure.