[kiesel]

The update mechanism itself is still insecure, as the wordpress instance must have the ability to exchange its own source code - something you'd at least call risky. Web applications should run with the least possible privileges, ie. only with permissions to write to dedicated locations on the filesystem (user uploads), and read permissions for the code.

PHP has composer, a dependency management system. There's an option to build a wordpress project using composer.

Even more, there's even a boilerplate project that you can use to bootstrap your new wordpress setup - see https://roots.io/bedrock/

[CiPHPerCoder]

> Web applications should run with the least possible privileges, ie. only with permissions to write to dedicated locations on the filesystem (user uploads), and read permissions for the code.

This isn't wrong but I'd argue it's a lower priority concern than you believe it is.

A comprehensively secure automatic update system would have process isolation between the normal web interface and the updater (and the latter would run as a different, more privileged user). However, not everyone can do that. (Shared hosting, etc.)

https://paragonie.com/blog/2016/10/guide-automatic-security-...

The goal of an automatic update mechanism should be to prevent the rampant exploitation of 1days, like what happened with Drupal not too long ago.

If you had to choose between "owned within 7 hours of the advsisory" or "less theoretically secure in a constrained environment but still securely self-updating" in the CMS/blog threat model, the latter wins.

There's no easy way to rearchitect WordPress to support the principle of least privilege and process isolation for their auto-updater in a way that ensures everyone still uses it. So for the time being, that's worthy of being called out, but isn't a big enough deal to label the whole shebang insecure. Because "insecure in which threat model?"

[kiesel]

> A comprehensively secure automatic update system would have process isolation between the normal web interface and the updater (and the latter would run as a different, more privileged user). However, not everyone can do that. (Shared hosting, etc.)

That's right, and I also think the popularity stems from the simplicity and the fact that it existed when the whole blog thing took off.

There's actually the option to provide your FTP credentials in the admin console and have wordpress update itself over an FTP connection. It is process separation, then, but OTOH potentially exposes your webspace credentials to an attacker. :-)

[ahje]

Problem is that there's a ton of shared hosting providers that won't support such a setup, as it would require a lot of modifications to 1-click-installers for WordPress. General WordPress users have no idea about such things, and the demand for more elegant solutions is therefore quite small.

That, and the fact that WordPress popularity stems from the fact that it's fairly easy to set-up without technical know-how, makes it unlikely that another path will be chosen in the close future.

[zelon88]

Can you elaborate on the specific threats you're thinking of?

I'm picturing a WordPress environment where all the source code owned by root with R+X permissions for www-data and nobody else, and an "Uploads" directory owned by root that has R+W for www-data with no X.

So assuming we have locked down permissions but still running a vulnerable plugin; we still have code execution and can ex-filtrate secrets via Uploads or create symlinks or upload malicious payloads. We just can't use the webserver to change code. You could still steal credentials that give us access via other means.

[kiesel]

By being able to modify executable files on the webserver, an attacker can add a backdoor through a security hole quite easily. Without, he could just make use of the security hole as of itself.