4 ms·

> At times like this, I really wish there were more best practices to mitigate against these type of vulnerabilities. There are many best practices: - Use v

> At times like this, I really wish there were more best practices to mitigate against these type of vulnerabilities. There are many best practices: - Use version control. - Have remote backups for the past day, week, month, etc. - Apply security patches immediately (and have test infrastructure so you can make sure they don't break anything). - Be able to rebuild a server from scratch w/ backups (configuration management really helps here). - Subscribe to security mailing lists/RSS feeds/Twitter accounts. This vulnerability is pretty bad, of course, but there have been many like it before, and there will be many like it in years to come. If nothing else, use this situation to prepare for the worst on your own site; how would you respond if your site was hacked, your database in an unknown state, and your codebase potentially backdoored?

dageshi 12y ago
To be honest, it's not actually as dire as it may seem in my opinion. Consider, if you're on shared hosting, which a lot of drupal sites will be then the server itself isn't your problem only the site is. Copy the site off and have your host reinitialise a clean account, that's taken care of. In terms of the site you're looking for code backdoors, there are a relatively limited number of places these can live. You can completely overwrite drupal core + contrib modules with good clean versions, that really limits the places where bad code can live to the files directory and the themes directory. Files for the most part shouldn't contain any executable scripts so locating backdoors there is relatively easy. The theme will contain php files but their number is relatively limited and is primarily templating related, it should be possible to find bad code here if you know what you're looking for, after all the theme doesn't handle authentication so can't exactly introduce subtle 1 character tweaks here to make the site vulnerable. The database is more complicated unfortunately, besides simple privilege escalation and permission alteration which are relatively easy to find, drupal often allows php to be stored and executed from within the db. I can see if an attacker is particularly sophisticated a backdoor in there being harder to find, but I imagine there will be people working on tools to hunt that kind of thing in the imminent future.
eropple 12y ago
Configuration management is an enormous pain for systems like Drupal that are essentially built ad-hoc, though. It's not something that's practically baked into something like Chef unless you're willing to spend a ton--a ton--of time baking your assumptions into code. And that (along with stuff like a test infrastructure) assume the capability of even doing it; Bob's Bait Shop does not have the technical staff necessary to act according to best practices but definitely needs a website. ("Use SquareSpace" is rarely an answer, though depending on the project it can be; anything remotely clever is going to need to go outside of the usual SaaS providers and that's why there are so many rickety Drupal sites out there. I used to write them, I know.) Once again, software is harder than it needs to be. Gary Bernhardt has been going into this in depth on Twitter lately, and I agree with him more and more as I pay more attention to the shitshow around us.
- noir_lord 12y ago
  > Configuration management is an enormous pain for systems like Drupal As someone who worked on Drupal for a couple of year in the days of 5/6 this was my biggest problem. I don't think things have improved much.
  - geerlingguy 12y ago
    Things have improved greatly! With Drupal 7, there are two main solutions, the configuration management module, and features. With Drupal 8 (likely coming out within the next year, currently in beta) YAML-based exportable configuration management is baked into core and will be much more accessible for custom development and contributed modules.
    - eropple 12y ago
      Sure. Now they need to grapple with the fundamental differences between install-and-tweak and design-through-code to actually make this meaningful in a modern (Chef/Puppet/Docker) environment. I won't be holding my breath.
      - 12y ago

dageshi 12y ago

To be honest, it's not actually as dire as it may seem in my opinion. Consider, if you're on shared hosting, which a lot of drupal sites will be then the server itself isn't your problem only the site is. Copy the site off and have your host reinitialise a clean account, that's taken care of. In terms of the site you're looking for code backdoors, there are a relatively limited number of places these can live. You can completely overwrite drupal core + contrib modules with good clean versions, that really limits the places where bad code can live to the files directory and the themes directory. Files for the most part shouldn't contain any executable scripts so locating backdoors there is relatively easy. The theme will contain php files but their number is relatively limited and is primarily templating related, it should be possible to find bad code here if you know what you're looking for, after all the theme doesn't handle authentication so can't exactly introduce subtle 1 character tweaks here to make the site vulnerable. The database is more complicated unfortunately, besides simple privilege escalation and permission alteration which are relatively easy to find, drupal often allows php to be stored and executed from within the db. I can see if an attacker is particularly sophisticated a backdoor in there being harder to find, but I imagine there will be people working on tools to hunt that kind of thing in the imminent future.

eropple 12y ago

Configuration management is an enormous pain for systems like Drupal that are essentially built ad-hoc, though. It's not something that's practically baked into something like Chef unless you're willing to spend a ton--a ton--of time baking your assumptions into code. And that (along with stuff like a test infrastructure) assume the capability of even doing it; Bob's Bait Shop does not have the technical staff necessary to act according to best practices but definitely needs a website. ("Use SquareSpace" is rarely an answer, though depending on the project it can be; anything remotely clever is going to need to go outside of the usual SaaS providers and that's why there are so many rickety Drupal sites out there. I used to write them, I know.) Once again, software is harder than it needs to be. Gary Bernhardt has been going into this in depth on Twitter lately, and I agree with him more and more as I pay more attention to the shitshow around us.

noir_lord 12y ago
> Configuration management is an enormous pain for systems like Drupal As someone who worked on Drupal for a couple of year in the days of 5/6 this was my biggest problem. I don't think things have improved much.
- geerlingguy 12y ago
  Things have improved greatly! With Drupal 7, there are two main solutions, the configuration management module, and features. With Drupal 8 (likely coming out within the next year, currently in beta) YAML-based exportable configuration management is baked into core and will be much more accessible for custom development and contributed modules.
  - eropple 12y ago
    Sure. Now they need to grapple with the fundamental differences between install-and-tweak and design-through-code to actually make this meaningful in a modern (Chef/Puppet/Docker) environment. I won't be holding my breath.
    - 12y ago