Posted by Bevan on October 31, 2014 at 10:56pm
The Sophos article on the Drupageddon followup PSA makes a solid argument for an auto-upgrading system built into Drupal, as an effective means to reduce the impact of things like Drupageddon.
Wordpress already has such a thing. Drupal already has a self-upgrading system, but it is not automated or promoted as a useful tool for securing a website. It also doesn't support patching (though that might not be necessary).
Thoughts?
Comments
I think this discussion is
I think this discussion is happening on this core issue: https://www.drupal.org/node/2367319
This goes directly against
This goes directly against Securing file permissions and ownership.
Having the webserver process have write access to the site files is a huge security problem. This would be required for self-update. Drupal also makes attempts to make sure that any user uploaded content can't be executed (cf, the .htaccess rules for tmp, public, and private). The PHP filter is also on death's door for similar reasons.
When you do this you not only have to worry about Drupal being secure, but you are also open to Apache / PHP security problems making core alterable w/o the site owner knowledge.
Many of the Wordpress problems can be attributed to the fact that many people run it on shared hosting, where FCGI runs as the user account, and exploits inject themselves directly into the common wp-theme files, like footer.php.
It can be done securely if
It can be done securely if Drupal FTPs into itself via an FTP or SSH service on the same server. That is what the self-updater in Drupal 7 does.
Thanks for the link Michael; I suggest future discussion happen there instead of there. Sorry I didn't think to look for this in the issue queue first.
https://www.drupal.org/node/2367319
Bevan/
@mpdonadio - yes, I think the
@mpdonadio - yes, I think the suggestion in the article is flawed or even shows ignorance of the problem space. However, I think making updates more automated or providing helper scripts with drupal itself could help less expert users keep up to date.
Honestly, I dislike the very
Honestly, I dislike the very idea of a web application having the ability to modify its own code. It fails outside of version control. It introduces new attack vectors. It runs the risk of introducing bugs and breaking a site before proper QA.
Taking a step back, SA-CORE-2014-005 was an outlier in terms of the insane severity of the vulnerability. In this one instance, having the ability to quickly deploy a one-line core security patch would have been beneficial to the code base at large. But let us not forget that even well intentioned updates, such as 7.29, resulted in a bug that introduced data loss. While this is trivial in magnitude compared to 7.29, a contrib module might perform the reverse (where a minor security update introduces a major bug or a feature change in conjunction that causes a disruption in an enterprise site).
The only use case where I would be comfortable with auto updates would be brochure and/or blog sites because the impact of a broken site is not as high. In case it's not obvious, this is a somewhat ironic situation... where the stakes are low enough where we're willing to risk breaking a site or introduce a new bug by auto-deploying an update to patch known bug.
In short, while I see a use case, I fear the repercussions of users enabling and relying on this without understanding the repercussions.