Slashdot Mirror
Backdoor Found In WordPress Plugin With More Than 200,000 Installations (bleepingcomputer.com)
According to Bleeping Computer, a WordPress plug that goes by the name Display Widgets has been used to install a backdoor on WordPress sites across the internet for the past two and a half months. While the WordPress.org team removed the plugin from the official WordPress Plugins repository, the plugin managed to be installed on more than 200,000 sites at the time of its removal. The good news is that the backdoor code was only found between Display Widgets version 2.6.1 (released June 30) and version 2.6.3 (released September 2), so it's unlikely everyone who installed the plugin is affected. WordPress.org staff members reportedly removed the plugin three times before for similar violations. Bleeping Computer has compiled a history of events in its report, put together with data aggregated from three different investigations by David Law, White Fir Design, and Wordfence. The report adds: The original Display Widgets is a plugin that allowed WordPress site owners to control which, how, and when WordPress widgets appear on their sites. Stephanie Wells of Strategy11 developed the plugin, but after switching her focus to a premium version of the plugin, she decided to sell the open source version to a new developer who would have had the time to cater to its userbase. A month after buying the plugin in May, its new owner released a first new version -- v2.6.0 -- on June 21.
I think it's a tradeoff. Do you need blogs, commenting, authentication, permission systems, easily updatable content by non-technical users, etc? For example, rolling your own authentication system is easy. Rolling your own that isn't vulnerable to DDOS and SQL-injection attacks is a really hard problem that people have already solved within most frameworks or CMS systems. In this case, a CMS might be worthwhile. However, ff you just need a couple of static pages that don't require regular changes, then skip it. But if the client can't be bothered to spend the money and time for regular maintenance and security patches, then they should just be directed to a WYSIWYG end-to-end system that offers the whole thing as a managed service.
There is Django and several frameworks that are easy to learn and fairly secure if you know what you are doing. How many sites need all these things CMS provides? If they do then a complex monster like SharePoint might be useful but these are small unless you work for a fortune 500 company.
The people who use Wordpress are small business owners and most customers who want something cheap to setup and forget. Wordpress is defective by design as it doesn't auto update and have all the plugins auto update and be 100% compatible with itself. The whole thing is defective by design as 75% of the people who use do not have an I.T. department unlike those who work with these monster CMS packages and even if they do have an I.T. guy or two they never will check Wordpress as the boss might be pissed if the update breaks something etc.
http://saveie6.com/
I've been down that road, but managers kept asking for additional features that were readily available in existing CMS's or their pluggins. I spent a lot of time re-inventing the wheel and was always behind.
I'd like to see more "generative" systems that generate static HTML from a CMS and uploaded automatically and periodically via a one-way FTP connection. (The internal draft may be dynamic.) It's harder to hack static HTML. I know generative CMS's exist, but they never caught on for some reason.
And it's not that WordPress is "bad", it's that any flaw found exposes a vast number of sites due to its ubiquity (and plugin ubiquity). I've found security flaws in my roll-your-own system. Humans make mistakes. It relied on security-through-obscurity, not perfection. STO is a consolation prize in security-land.
Table-ized A.I.
This situation doesn't back up your point at all. Technical considerations about features and what's easy to learn versus hard to learn are remarkably subjective. What's objectively clear is that Sharepoint (a proprietary CMS) doesn't allow users to inspect what it's doing, alter the code, or share improved versions. Any problems with Sharepoint have to be fixed by the proprietor (Microsoft), and a backdoor in Sharepoint may well not be viewed as something that needs to be "fixed" from the proprietor's point of view.
WordPress, by contrast, respects a user's freedom to run, inspect, share, and modify. Site owners can decide how much time and effort they want to put into keeping their WordPress install secure. If they find a problem, improvements can be vetted, shared, and completely understood. The limits of review and improvement are the site owner's to choose and site owners retain the freedom to fully control their site (so long as they host on free software systems). Even bad free software (for any definition of "bad") is better than nonfree software because users have software freedom. Writing one's own code would grant one the freedoms only Microsoft gets with Sharepoint.
It's not fair to WordPress to conflate a WordPress plugin with WordPress itself ("Wordpress is a joke") or being horribly vague about what is so bad about various free CMSes. WordPress can't take responsibility for what others put in their WordPress plugins. They can only delist the malware plugins and describe why users shouldn't run that plugin downloaded from another source.
Finally, your point fails to describe how this particular WordPress plugin is critical to useful WordPress sites. This matters to WordPress' main audience—nontechnical users—who might want to know why they should not want particular functionality the plugin ostensibly delivers, or how to get comparable functionality another way. Lots of users aren't technical and won't know why they shouldn't install a bunch of plugins, or how to vet the plugins they find provide genuinely necessary functionality (including not blindly accepting every upgrade but vetting the changes along the way). I don't like malware either, but it's not fair to conflate software freedom with non-freedom (as if nonfree software was inevitable or just as reasonable a choice, an alternative), or to blame one party (WordPress in this case) for another' choices, and objections are far more useful when they are specific.
Digital Citizen