Disclosure of Additional Security Fix in WordPress 4.7.2
make.wordpress.org
make.wordpress.org
Currently, we are seeing people probing this vulnerability.
I have used modsecurity before and found writing rules difficult, so happy to pay.
As Sucuri notes:
> We disclosed the vulnerability to the WordPress Security Team who handled it extremely well. They worked closely with us to coordinate the disclosure timeline and get as many hosts and security providers aware and patched before this became public.
https://blog.sucuri.net/2017/02/content-injection-vulnerabil...
In my opinion the implication of what they did means people who don't host with Wordpress or Wordpress's partners will have to wait longer for security patches. That gives Wordpress and their partners a very clear business advantage - "host with us or be vulnerable to attack until we get around to releasing our patch publicly".
That doesn't necessarily mean WP were in the wrong though. It's possible there simply wasn't a better approach - releasing a patch that doesn't fix the problem can be worse than waiting until you have a good fix, and you definitely can't disclose a problem until you have a strong fix.
Put simply, disclosing vulnerabilities is hard.
This is so true!
To try to set the record straight, WordPress.org (the open source project) doesn't host and websites apart from our own (WordPress.org, WordCamp.org, BuddyPress.org, etc). So people can't host with us. Also, while we do have some recommended hosts that have helped the community as well as put a lot of effort into making their WordPress hosting really exceptional, they were not the only hosts we worked with on this (or even the majority).
Additionally, the work with hosts and WAFs happened in parallel with the work on the patch. WordPress users are our priority and they exist at pretty much every host. The best way to secure them all is to get a patch out. Anything we can do to mitigate the risk between finding out and when that patch is ready, is really just a bonus :)
They had to balance the question of getting as many installs as possible protected before doing the easy-to-analyze release, because probably within hours after the release there were going to be attacks starting to turn up. In the meantime, as long as they had feedback from the WAF vendors that the vulnerability wasn't being probed they had a pretty good idea that it wasn't widespread.
The only real question about it that I was curious about as well is which firewall plugin developers they communicated with.
Marc, the researcher that found it, wrote the technical details here:
https://blog.sucuri.net/2017/02/content-injection-vulnerabil...
thanks,
Google just gives me a bunch of content spam, but I know that there's gotta be some best practices I can employ.
2. Don't disable autoupdates.
3. Avoid plugins and external themes. If you can stick to Wordpress Core. If you use plugins use as few as possible and only ones that are maintained regularly. Keep plugins and themes updated.
4. Don't disable autoupdates.
Also, have I mentioned you shouldn't disable autoupdates?
You could decide to not upgrade when a new major version comes out, like 4.8.0, but wait till there is a 4.8.1. Often there is a rush to pack new features in a new release, and the first update often has quite a few security fixes.
Also, be picky about which plugins and themes you use. And if you notice that one becomes unmaintained (no updates anymore), make a plan to switch to something else. /edit: Commercial themes are often overloaded with lots of functionality that you don't need. If you care about security, avoid them.
There are also plugins like WordFence, which might be a good idea (I don't really know). Most things that are in there should really be handled serverside, like mod_security rules and firewall rules. This topic is about WAF rules, which are serverside done afaik.
If you just use shared hosting and have no control over the server, using WordFence might be a good idea.
(I maintain three WP myself by hand, but that's me being a control addict.)
WP's core security is vastly better these days. So instead you'll fall prey to a cruddy plugin or theme ... especially the latter, being PHP written by designers. (Nothing against good designers, but design thinking is not security thinking.)
A really useful shortcut: put /wp-admin/ behind Apache basic auth. This stops most doorknob-rattling automated 'sploits in their tracks. (Main barrier to doing this in practice is that nontechnical editorial people tend to get confused by two layers of password.)
I keep my Wordpress and plugins up-to-date, but they still kept finding ways in. What finally worked for me was to write a simple front-loader to replace the Wordpress front-loader. It has a whitelist of allowed $_POST fields, a blacklist for $_POST content, and it deletes anything in $_FILES unless the user is on a whitelisted IP. This has kept the site safe for several years now so far.
Mine is an extreme case, but maybe this approach will be helpful to other extreme cases.
Grr. Checked some sites, and the auto update hadn't yet upgraded to 4.7.2. Guess I get to go figure out why now.
If you want an auto-update, why not do this with an automatic CI/CD type pipeline that's triggered on new WP versions?
One reason is because WP updates often need database upgrades too. I've been updating using `wp-cli` which can be run via cron -- but I've yet to sort what to do when WP/a plugin needs the 'Upgrade database tables' button clicked.
A CI/CD pipeline would be nice, especially with a verification stage that confirmed the website hadn't changed post-update (yesterday, updating a plugin lost data. Sore point)
I do see your point, but wordpress just isn't designed to work that way. And, if you did go through all the hoops to make wordpress okay without write access to files, it still has write access to the database.
I do have other mitigations in place, and feel like the risk profile is fine for what these sites do (informational only).
I'd be happier if the auto update was working as it should though.
You can disable the file write features of WP and remove the online application upgrade feature. This leaves you using your code repo and build system as the proper path to upgrading the code. This allows you to vet any code change to your site, which you should be doing anyway.
You mentioned the uploads directory, but there are very common plugins that need write access to other files. Almost every caching plugin for wordpress, as one example.
You also have to replicate the functionality to do upgrades for plugins, themes, and core WP, including ones that need database upgrades.
It's just a risk management decision. In my case, all the hoops to make the filesystem read-only aren't worth it. Retaining the built-in upgrade functionality is of higher value. We have offsite backups and file integrity scanning, and will fall back if needed. If the sites were, say, e-commerce sites, I would have made a different decision.