WordPress ought to issue deprecation notices, really
-
Hello,
I found on a wordpress blog of mine a plugin whose last update was three years ago.
As a security freak, I’m blaming myself real hard, but I think wordpress can’t entirely skip the blame here.
Look, I’ll be generous and share 1% of the blame with WordPress.Irony aside : as a CMS installed on millions of websites, if not hundreds of millions, I think it should be obligatory that the blog engine notifies us when a component is apparently abandoned.
Let’s look at the plugins page in the blog admin : there is no mention of how old the plugins are. It’s a tedious task to check.
Once we own several blogs, it’s too easy – we’re only humans – to forget some important possible security holes, like deprecated plugins.
I’ve posted negative feedbacks about security in the past (like here and there), let us call this a new iteration.
I’m not saying the wordpress team isn’t doing anything, I know you guys are working hard, okay ??
But, well, it’s true there is still the need for improvements in the security field, like in the present case.A constructive proposition : that it’s on blog core updates (new wordpress versions) that a check is ran for how long ago were the plugins last updated. (I don’t see this applying to themes, some themes don’t need monthly updates and are thought as mostly fixated once created, and then there would be the child themes issue.)
And if we’re talking about delays superior to a year, we have a warning show up on top of the blog admin pages, with a little cross to close/dismiss it, and only be notified on the next wordpress update.
-
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.
Welcome to the internet. We also have cat pictures.
There is no simple way to know if any product you use is safe or tested unless you actually do so yourself. We do our best, but nobody is perfect. Your ideal is an unattainable one.
“Welcome to the internet. We also have cat pictures.”
Wow. That about sums it up, doesn’t it? We don’t have to worry about security because cat pictures?
I am floored.
“Your ideal is an unattainable one.”
The ideal that wordpress might actually test plug ins, set standards, and adhere to them so that people can’t easily create code that turns malicious? I would think you more than most would understand where most of the security issues come up- plugins and themes, and mostly because they do things to work around the core or do not use proper sanitizing when accepting inputs and processing them outside the core.
Perfection cannot be obtained. Takings steps to try to make the products offered on your service as safe as possible is ALWAYS obtainable… if you want to do it.
You do realize that there’s 35000 plugins, and we didn’t write most of them, correct? We offer plugin hosting here as a service, but we don’t control the content of them in more than a minor way.
I am floored that you think such things are possible by unpaid volunteers. Or, are you volunteering to perform that massive amount of work?
“You do realize that there’s 35000 plugins, and we didn’t write most of them, correct? We offer plugin hosting here as a service, but we don’t control the content of them in more than a minor way.”
I think that part of the problem is there: There is no simple way for the public to know the difference. When they come to wordpress and download the software and add in some plugs ins an themes off the wordpress site, the thought process is that what is on the site is approved, vetted, or at least held up to a certain standard by wordpress itself.
“I am floored that you think such things are possible by unpaid volunteers. Or, are you volunteering to perform that massive amount of work?”
Perhaps then wordpress should part with a little of the gold and get some actual staff. Millions of installs, tons of plug in and theme downloads per day (often freemium things that don’t do much of anything until you pay)… somewhere in there, there has to be enough of a business model to help protect the ecosystem from swallowing itself.
Perhaps the issue is 35,000 plug ins. Quantity over quality?
Oh, and no, I am not volunteering to come clean up the mess that has been made with this, unless it pays really well. It will likely have to in order to get anyone willing to rake through the muck.
somewhere in there, there has to be enough of a business model to help protect the ecosystem from swallowing itself.
So here’s a quick query on a certain search engine:
risk management
noun
(in business) the forecasting and evaluation of financial risks together with the identification of procedures to avoid or minimize their impact.And from a really good Wikipedia page:
For the most part, these methods consist of the following elements, performed, more or less, in the following order.
- identify, characterize threats
- assess the vulnerability of critical assets to specific threats
- determine the risk (i.e. the expected likelihood and consequences of specific types of attacks on specific assets)
- identify ways to reduce those risks
- prioritize risk reduction measures based on a strategy
I’m bringing this up because I want to look at what you are describing in terms of risk management and mitigation.
The part I highlighted was “the expected likelihood”. Yes, the risk that you are describing in length has happened before (exploitable code).
But what is the likelihood of that happening in volume? I am not asking if it could happen, I am asking out of those 35,000+ plugins what is the expected number of that occurring? It’s a graph-able chart but I’ve not bothered to do the math.
The volunteers that patrol the code do so on their best effort. The work that you are describing is monumental but the risk doesn’t really justify that astronomical effort.
When an exploit is determined it get’s handled professionally, which for a team of volunteers is remarkable. Some of that handling is extreme and performed on a break glass case. The recent forced upgrade of Yoast’s SEO plugin is an example of that. Most often the handling involves upgrading a theme, plugin or core WordPress. That’s the majority case.
It’s fine to describe the situation you see as a problem, but there’s no company to invest that gold into solving it. And while getting to that ideal nirvana* may be laudable there’s not really a good case for that work to be anything more than best effort.
If you want to participate in that effort (and you’ve made it clear that you don’t desire that) then please do.
If you are trying to build a case where others do that level of work… the incident numbers really aren’t there to support that huge effort.
*NOTE: If you are impacted by a vulnerability and your site was compromised then that is the worst. That really sucks. I’m not minimizing that pain. But to do this huge work for what really is an intellectual exercise doesn’t really solve the problem when it occurs.
There is no simple way for the public to know the difference.
There’s no simple way for anyone to know the difference. I was one of the plugin devs hit by the example.html issue in Genericons. I was removing it anyway for unrelated reasons, but seriously, I review WP plugins every single day and I missed that too! It’s an html file, from criminy’s sake!
There’s no simple way to say “Security!” and yank a plugin and alert people without simultaneously alerting all the naughty people out there :/ We talk about it a lot. There’s really no good way. We do inch towards better all the time though.
(PS: Please use
<blockquote>
tags around your quotes. Make’s more readable ?? )Ipstenu, security issues happen to everyone. This one happened to point out something very significant, which is needless repetition of code such as genericons. If it’s something being used often, shouldn’t it be a stand alone plug in or “common file” that can be used by many, and could easily be updated or patched based on security issues? Depending on each plug in creator to update their code is to expect failure. Not everyone is active, not everyone is willing.
But what is the likelihood of that happening in volume? I am not asking if it could happen, I am asking out of those 35,000+ plugins what is the expected number of that occurring? It’s a graph-able chart but I’ve not bothered to do the math.
With a large number of wordpress installs that I take care of, I can tell you that I run into errors and problems all the time. Themes updated that no longer work at all (did anyone test it?), recently a theme that entirely dropped the title tags from display. Plugins that cause security issues, themes with tons of java code that is almost always somewhat buggy. They may not be security errors, but they are certainly annoying. The sliders and various gallery uploader tools that have security errors is a pretty long list at times.
Moreover, anyone who logs larger sites will know how many security issues there are. The average script kiddie banging my wordpress installs right now are looking for about 50-80 different packages that have known exploits. That’s just current ones. Who knows how many older ones they just stopped looking for because they code isn’t that common anymore.
I can also say that among 35,000+ plugins, I would guess that somewhere around 10% of them are actually valid and up to date, and the rest are the great unknown. Risk Management (I use to do insurance claims, know the concept) says that the 10% up to date generally won’t be your risk, but the 30,000+ untouched and unloved plugins will be someone’s downfall. You can easily reduce the risks by locking up and potentially eliminating plugins that are no longer maintained and no longer up to date.
You will point to some that are great and not updated. Well, go in and update them as compatible with the current version, and the problem is solved. It is much easier to handle a few known good plugins rather than to leave hundreds or thousands of potential headaches out there waiting to screw up. It could be something as simple as not being compatible with the current version and screwing up someone’s files, it could be not being compatible with current PHP versions… there is a host of potential issues that can be mitigated by retiring old code and deprecating old plugins that are no longer supported and may cause issues.
With a large number of wordpress installs that I take care of, I can tell you that I run into errors and problems all the time.
OK, I’ll bite. Which specific theme or plugin or WordPress vulnerability did you run into that would have been mitigated by a code review or deprecation notice? If you mean the plugins that were covered by the recent announcement then thanks! The current process works. ??
The WordPress dashboard on your installation will not produce hits for plugins that are more than 2 years old.
I can also say that among 35,000+ plugins, I would guess that somewhere around 10% of them are actually valid and up to date, and the rest are the great unknown.
More bites. ?? How did you empirically arrive at that number? I’m guessing it’s just a thumb-in-the-air-seems-alright-to-me statement. But why 10%? Why not 75% or 5%?
Moreover, anyone who logs larger sites will know how many security issues there are.
See this reply from way up top. This really is not a topic where your not knowing what/why those logs are there equates with insecure.
You can easily reduce the risks by locking up and potentially eliminating plugins that are no longer maintained and no longer up to date.
It’s not easy. That’s been covered.
I’m still not clear about the risk you refer to but as I’ve pointed out: the WordPress dashboard on your installation will not produce hits for plugins that are more than 2 years old.
It’s for the compatibility concern that that is in place. Yes, you can install a plugin manually but it does not introduce anymore security risk when you do that. Be it a new plugin or old, the potential for risk is still low.
Well, go in and update them as compatible with the current version, and the problem is solved.
Now, that’s a non-starter. You’re attempting to make a case for others to do a great deal of work without offering to get involved. That’s fine but you’re not making a compelling case. The real numbers based on incidents from old plugins or themes do not support that effort.
Which specific theme or plugin or WordPress vulnerability did you run into that would have been mitigated by a code review or deprecation notice?
Well, two I see often getting tested is Symposium and WP All Import. Yes, both of them have since been fixed, but both of them also had problems related to non-secure file upload / file creation. Both seemed not to do proper file name and type sanitizing, something that would have likely been handled if they had used core functions rather than their own.
Flawed versions in use in the wild must be significant enough that the scripters are actively looking for them TODAY.
The WordPress dashboard on your installation will not produce hits for plugins that are more than 2 years old.
I don’t use it. I come to worpress.org and search for plugins. I get all sorts of stuff, new and old turning up. Stupid me for using the site, right?
More bites. ?? How did you empirically arrive at that number? I’m guessing it’s just a thumb-in-the-air-seems-alright-to-me statement. But why 10%? Why not 75% or 5%?
Let’s look and see. I use a very simple search: Tweet. 9 pages. 33% (3 pages) are a year or less on updates. 1.5 pages are actually updated to current version. 16% are up to date, and 66% of them are out of date or even WOEFULLY out of date. Since wordpress itself doesn’t offer any support back very far, why would you even think it’s useful to have these plugins available?
This really is not a topic where your not knowing what/why those logs are there equates with insecure.
A simple search on Google for almost every one of the things getting hit leads to an exploit page. Most of them are fixed. Most of them have very simple exploits that could have been avoided by enforcing use of core functions for file transactions and requiring proper access / use security via the core. Failure to apply such standards means that the next security exploit plug in or theme is “just around the bend”.
I’m still not clear about the risk you refer to but as I’ve pointed out: the WordPress dashboard on your installation will not produce hits for plugins that are more than 2 years old.
I still point out that a simple search on www.ads-software.com presents a near endless list of out of date plugins. That doesn’t even being to cover plugins from third parties not listed on wordpress but that can be used because there is no simple versioning protection within wordpress.
You’re attempting to make a case for others to do a great deal of work without offering to get involved.
I am getting involved, by showing up and mentioning the the emperor has no clothes, or at best a flesh colored bodysuit that isn’t very flattering.
The “great deal of work” isn’t very hard actually – you guys have all the stats for number of installs, activity, and the like. Start by eliminating what is old, not updated, seldom downloaded… send a notice to the creator that you intend to deprecate it as untended and of unknown security standards. If you find a plug in that is popular but untended, try to find the creator to get back to it, try to get someone to take over the code, or if it’s really useful, give it a code review and bring it up to date.
The real numbers based on incidents from old plugins or themes do not support that effort.
Based on the amount of script kiddies looking to hit that stuff, I would say the problem is much larger than you are seeing. Seeing how many attacks on wordpress sites come from other compromised wordpress sites (it happens often enough for me to notice it)… that means there is enough out there and the message isn’t getting out.
There is no simple answer. However, sticking your head in the sand and saying “from your install, you can’t see those things” isn’t going to make it better.
The “great deal of work” isn’t very hard actually.
You realize the work you’re asking us to do, then mocking, will take at least a month if not more of solid dedicated time, right?
You also realize that we’re all volunteers, right?
So, you acknowledge that, much like how you have little interest to participate beyond like leaving threads like these, we might also have little interest in giving up our volunteer time for a months-long project that will produce little-to-no results?
I don’t really have any answers for you, I just want to make sure you’re aware of those points, because going back through your previous threads, you seem to be unaware that WordPress is free software backed by a non-profit organization and developed/supported entirely by volunteers.
No one is sticking their heads in the sand. Rather, no one has time to take this on, no one is stepping up to volunteer for it, and you have made it plainly clear that you won’t either.
Security is taken very seriously be the security team: https://www.ads-software.com/about/security/ They’re volunteers too, and if you’re interested, WordPress is always in need of more volunteers.
You realize the work you’re asking us to do, then mocking, will take at least a month if not more of solid dedicated time, right?
You also realize that we’re all volunteers, right?
I understand in the grand scheme of something that has been available and maintained for 10 years, 1 month isn’t a lot of time.
I don’t really have any answers for you, I just want to make sure you’re aware of those points, because going back through your previous threads, you seem to be unaware that WordPress is free software backed by a non-profit organization and developed/supported entirely by volunteers.
I also understand that with more and more people using wordpress and more and more corporate (and political) customers using wordpress, it won’t be long before something will blow up and all the efforts put in to date will be lost as people tend to run away fast from security issues.
It’s also nice to play the non-profit card, but Automattic sure ain’t suffering. Just sayin’…
If I wanted to volunteer and wanted to work on the product, I would have done so years ago. I already spend 18 hours a day working as it is, I don’t have any room to take anything else on. I am not going to volunteer and then spend my time complaining that I don’t have time to deal with the issues.
It’s also nice to play the non-profit card, but Automattic sure ain’t suffering. Just sayin’…
Automattic is an entirely separate entity from WordPress.
Automattic’s CEO is the founder of WordPress, Automattic uses WordPress for its WordPress.com blogging platform product, and Automattic in turn donates server resources to the WordPress Foundation, but that’s where any sort of business/partnership relationship ends.
I already spend 18 hours a day working as it is, I don’t have any room to take anything else on. I am not going to volunteer and then spend my time complaining that I don’t have time to deal with the issues.
It’s good to hear that you know what it means to be a volunteer while also working a normal day job. ??
Volunteers here also have their day job.
I run a company that makes WordPress websites and I’m volunteering in my job time and out of my job time.
Meetings for me with the rest of the WordPress team is at 1am my time.
Many companies have also started setting up their Five for the Future rule – see https://ma.tt/2014/09/five-for-the-future/
Perhaps you should think a little like that, and if you can’t make the decision, make the effort to talk to your boss.
Be the change you want to see in the world.
And as James said – www.ads-software.com is ran by the Foundation and is non-profit, no one here is paid for doing work on www.ads-software.com
On that part, you are mistaken.
Lastly, all you’re doing is asking others to do the work, of which, all of us are using up any available time we have to perform the volunteer based tasks here.
The volunteers are doing the best they can and if you want us to do more, we need more volunteers.
If you are not stepping up, then where are your expectations coming from?
In any case, feel free to make good points on where we can improve. But if this discussion continues in the direction where the hard work of volunteers are being dismissed, or even mocked. I will close the topic.
Stop the blame game and step up.
This thread is now going round in circles and has veered well of topic. The poor original poster, who had his question answered weeks ago. Probably doesn’t want the continual barrage of emails in his inbox so I’m going to close the thread.
- The topic ‘WordPress ought to issue deprecation notices, really’ is closed to new replies.