
Disclosure of Additional Security Fix in WordPress 4.7.2 - tobltobs
https://make.wordpress.org/core/2017/02/01/disclosure-of-additional-security-fix-in-wordpress-4-7-2/
======
jgrahamc
Because of the severity of the issue we decided to roll out WAF rules for all
our customers (i.e. including those that don't get the WAF because they are on
a free plan): [https://blog.cloudflare.com/protecting-everyone-from-
wordpre...](https://blog.cloudflare.com/protecting-everyone-from-wordpress-
content-injection/)

Currently, we are seeing people probing this vulnerability.

~~~
porker
Does anyone know of a set of WAF rules - free or commercial - that I can use
on my server, rather than outsourcing to Sucuri or CloudFlare?

I have used modsecurity before and found writing rules difficult, so happy to
pay.

------
amq
The title implies that WP did something wrong, but did they?

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...](https://blog.sucuri.net/2017/02/content-injection-
vulnerability-wordpress-rest-api.html)

~~~
onion2k
_The title implies that WP did something wrong, but did they?_

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.

~~~
aaroncampbell
_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 :)

------
danielcid
We are seeing attacks in the wild for it already. Mostly defacement attempts
at the moment.

Marc, the researcher that found it, wrote the technical details here:

[https://blog.sucuri.net/2017/02/content-injection-
vulnerabil...](https://blog.sucuri.net/2017/02/content-injection-
vulnerability-wordpress-rest-api.html)

thanks,

------
bigmanwalter
Dear HN hivemind, do you have any advice for me on how to keep my client's
WordPress.org sites secure? A guide that you trust or maybe a good shared host
that takes care of these things?

Google just gives me a bunch of content spam, but I know that there's gotta be
some best practices I can employ.

~~~
hannob
1\. You're using Wordpress, that's already good. It has autoupdates. You're
unlikely to get hit by a vuln like this.

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?

~~~
bigmanwalter
What if my clients like their absurd selections of plugins and themes?

------
tyingq
_" The release went out over our autoupdate system and, over a couple of
hours, millions of WordPress 4.7.x users were protected without knowing about
the issue or taking any action at all"_

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.

~~~
lsaferite
This I don't understand. Why run WP where the server has ownership and write
access to the code? With the frequency that WP sites get attacked, leaving a
system in place where an attacker that gets access and can write files that
will be executed is just asking for problems.

If you want an auto-update, why not do this with an automatic CI/CD type
pipeline that's triggered on new WP versions?

~~~
CJefferson
But in this case, an auto-updating install would be protected, while a non-
updated version would now have the website over-written...

~~~
lsaferite
My point is, a publicly facing web application should not have permissions to
update it's own code. The possibility of the application being compromised and
then having the application modified to support further system compromise it
too great.

~~~
bigmanwalter
Well, that's how WP works so we're stuck with it. On the plus side, it makes
for a great plugin experience for non-technical users.

~~~
lsaferite
Having done WP installs where the only web-user writable area was for uploads
(and that is configured to not execute anything), I will have to dispute your
assertion. The fact that the vast majority of WP sites are web-user writable
is just inertia and/or bad security practices.

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.

~~~
tyingq
Yes, you _can_ do that, but you're fighting the way it is designed.

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.

~~~
lsaferite
Upgrades can be a single "composer update" and then committing the
composer.lock file. Mine are a bit more as I review changes between versions
as well. I am very careful about what plugins I use for this very reason
honestly. If it's not well-behaved enough and requires the ability to write
outside of uploads then it's not used.

------
edm0nd
Good thing [https://github.com/rastating/wordpress-exploit-
framework](https://github.com/rastating/wordpress-exploit-framework) exists

------
urbanj
Mods, can you edit the headline please - editorialising

------
droopyEyelids
flagged for editorializing the title

~~~
grzm
No need to flag: just comment what the correct title should be, and perhaps
contact the mods alerting them that it should be changed.

~~~
DrScump
Mods, when you _do_ retitle, please add a quick "title changed from (x) to
(y)" comment (most usually do) so we know when such complaints become
obsolete.

------
testUser69
Hopefully in 2050 our corporate overlords will still spend a week discussing
how to patch vulnerabilities in our 3D printed food databases too.

