Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Drupal Update Process Flawed By Multiple Bugs (softpedia.com) 55

An anonymous reader writes: The Drupal CMS, a favorite with large enterprises, has a few bugs in its update process, affecting both the Drupal core update and its modules. The biggest flaw of the three discovered by IOActive researchers allows an attacker to take over the sites via poisoned updates. What's worse is that Drupal's team had known of this issue since 2012, but only recently reopened discussions on fixing the problem.
This discussion has been archived. No new comments can be posted.

Drupal Update Process Flawed By Multiple Bugs

Comments Filter:
  • Not an issue. (Score:4, Insightful)

    by Falc0n ( 618777 ) <japerryNO@SPAMjademicrosystems.com> on Thursday January 07, 2016 @10:07PM (#51259677) Homepage
    One of the core reasons why this issue hasn't really been prioritized is because you really shouldn't be live updating your site. Not just Drupal, but I'd argue the same for Wordpress, Joomla, whatever -- its a bad practice. Why?

    Websites are very different from desktop or other normal applications. Most of these apps are tuned to your specific needs, and updates can cause issues. Serious Drupal shops and clients -never- live update their sites. Best practices suggest local or dev updates, which is then tracked by git. Site deployments should go through manual testing at a minimum. Many Drupal hosts don't even allow write access to htdocs -- only the files directory.

    For those who aren't involved in the ecosystem, this article can seem alarming. But as someone who works with Drupal, and its large clients, this is a non-issue. This issue was vetted by the security team, whom are pretty risk adverse; even they didn't believe this met the criteria to be a security issue.

    Should the Drupal update process be improved? Certainly. Is it a 'sky is falling Drupal sites are going to get hijacked?' nope. And for those who DO live update their drupal site, not maintain a git repo for their code, etc, etc.. Good luck. Like an default Linux install (also known to not be secure), Drupal cannot full-proof poor administrator practices.
    • Re:Not an issue. (Score:5, Insightful)

      by DNS-and-BIND ( 461968 ) on Thursday January 07, 2016 @10:37PM (#51259777) Homepage

      Serious Drupal shops and clients -never- live update their sites.

      I'm glad things are so great for you on Mount Olympus. Some of us AREN'T serious Drupal shops. We upgrade when the software says upgrade. When things break, like they shouldn't, we get pissed off.

      For those who aren't involved in the ecosystem, this article can seem alarming.

      Yaknow, the whole problem with Drupal is people like you who assume everyone is "in the ecosystem". Drupal has a big issue with it being by developers, for developers. I'm glad you work with large clients - really, I am - but when I the lowly user use a product, I expect it to work. I don't have a security team, I don't have a git repository, I don't have anyone to do manual testing. I just click upgrade when the system nags me to do so. And I think people like you forget or don't care about ordinary Drupal installations that get downloaded and serve pages. The fact that your last remark is borderline derogatory towards anyone who just clicks 'upgrade' I think tells a lot.

      • This is one of the reasons I've stayed away from Drupal. The community is pretty awful, in my experience.

        Now that I know they had a patch to move their update request to HTTPS back in 2012 - and ignored it - I'm definitely staying away.

        That's truly amateur hour.

        • by Anonymous Coward

          I abandoned dozens of Drupal modules I maintained because of that community. So glad I've moved on.

      • Christ, the sense of entitlement flows strong through this one. So let me get this straight. You or your company chose to use a FREE and open source tool to fulfill a requirement. Did you bother to do ANY analysis regarding whether the tool was an appropriate solution? The answer is most certainly "derr... No". Because if you had, you would have quickly realized that while Drupal has the ability to stand up a site within minutes, running a production site of ANY TYPE (internal or external) without any kno
      • Did you actually read the article, or did you just have a bad experience with Drupal (or its community)?

        I agree with the GP comment about the article's concerns. That's not saying there aren't real problems with Drupal as a whole when it comes to usability for noobs, or documentation, or getting enthuiastic community support anymore (it has died off some since the D7 to D8 community schism.

        But come on. It doesn't take a security team to deal with the article issues. And you don't even have to do manual test

      • Thanks for this.

        I used to write (and occasionally still do) small, re-distributable scripts meant to be run from shared/virtual hosts. It pisses me off to no end how almost all tools and frameworks are written under the assumption that you'll be running a dedicated server in an enterprise environment where the owner has some kind of admin access to install dependencies separately.

      • by orasio ( 188021 )

        Serious Drupal shops and clients -never- live update their sites.

        I'm glad things are so great for you on Mount Olympus. Some of us AREN'T serious Drupal shops. We upgrade when the software says upgrade. When things break, like they shouldn't, we get pissed off.

        You can pay someone to worry about that for you.
        It's pretty easy to move to a hosted Drupal service, so you don't have to worry about these issues, and get a nice SLA so you can complain to someone to make your site work for you.

        The web is a spooky place. It's becoming harder and harder to keep your web business online, without a serious team dedicated to secure it.

      • Also if we are not supposed to do live updates, why is there such a feature? Is it ok to provide a feature and create security vulnerabilities and then tell 'you shouldn't use it'?

        Are they simply telling Drupal is not for us and we should use something else instead?

        Because of the disappointment and frustration from v8, I'm seriously planning to move the wordpress.

      • by armanox ( 826486 )

        Even if you are not in the biz, the Drupal update page even tells you not to just upgrade. What does it say to do? Take your site offline, make a backup, and then run the upgrade process and check for errors. Yes, there is a certain level of knowledge required to run Drupal. I didn't find Sharepoint to be much simpler when I worked with that to be perfectly honest (the Drupal site I used to admin still pays me to do updates, a couple years later. The Sharepoint site that I am in charge of...the update

    • Re:Not an issue. (Score:4, Insightful)

      by gstoddart ( 321705 ) on Friday January 08, 2016 @12:51AM (#51260169) Homepage

      You've just described good release and change management. It's not unique to Drupal.

      And you would be utterly amazed at just how many places don't do such things. And, depending on the shop, if you feel agile works for you and you're not overly risk averse, you almost eschew such things -- because you are manly and if it breaks such is life.

      I don't use Drupal, and never have. But I do come from backgrounds where you go through a couple of promotions from a dev through to a prod, and test at each step. I do this because I've worked in regulated industries which are well beyond 'risk averse'. I learned to be paranoid in shops where lots of money and possibly human lives were on the line.

      But you would be utterly amazed at just how many people think it's a waste of time, or who will make live updates to a prod system. Far too many in fact. Some days I'm pretty sure Slashdot does it to their detriment.

      Those people can either tolerate some risk, or their employers aren't fully informed of the risks being taken on their behalf. Many places risk is unthinkable.

      Never underestimate just how widespread poor administrator practices are ... a lot of people are lazy, don't care, or are so over-confident you can't but expect them to drive off a cliff.

      I've seen far too many cowboys who always say "it will be fine" or think proper release engineering is a waste of time ... in my experience those people end up red faced and frantic when they finally do hose something beyond easy repair.

      It all depends on the industry you're in, and the consequences of failure. The problem is something you get some idiot who came from a place where the consequences would be minor who come along and fuck up at a place where the consequences aren't.

      Any system can fail spectacularly if you just wing it, do stuff in your live system, and assume you'll never have any problems. Some systems just help you fail more than others.

      • And you would be utterly amazed at just how many places don't do such things.

        Like here, for example?

        The logon problem seems to have gone away (touch wood), but there's been no explanation or announcement as to why. That in itself is pretty shit.

        • Like here, for example?

          Last sentence, 4th paragraph. ;-)

          I did take that swipe for those days when it suddenly says "Slashdot is in offline mode and we currently suck".

          Slashdot absolutely isn't afraid to screw up a live site.

      • by trawg ( 308495 )

        So I come from a webdev background; our formal practices for clients involve good release and change management, so I'm not a stranger to them.

        However, while things like Drupal and WordPress are often used as the basis for client projects by companies that do that sort of "best practice", I think it's important to remember that for many users, it's basically the equivalent of installing a new application on their desktop computers - they just click a bunch of things and presto, it is online.

        I guess there's

    • Drupal cannot full-proof poor administrator practices.

      When did that become a phrase? What would "full-proof" mean? It's immune to, what, being full?

      "Hey pal, you want the diet whiskey with that?"

      "No, I'll have the full-proof."

      How about "fool-proof"?

  • news for nerds
  • Drupal rocks :) (Score:3, Informative)

    by amoeba47 ( 882560 ) on Friday January 08, 2016 @04:31AM (#51260571)
    As someone who has developed with Drupal for several years, I just want to add a positive perspective to balance the expected usual negative comments here. Drupal is a great CMS and web application framework. Extensible and flexible it can be adapted for many applications. Moreover, the Drupal community is knowledgeable and helpful. Growing from strength to strength with each release, I love working with Drupal. That is all.
  • If I remember right, php didn't start checking peer ssl certs until 5.6. Then it doesn't really matter if http or https is used because php wouldn't even notice if the cert was invalid if you aren't on php >= 5.6.

  • Below are some quotes of the critical issues from the blog post and the Drupal Security Team’s analysis of the risks: https://groups.drupal.org/node... [drupal.org]

FORTUNE'S FUN FACTS TO KNOW AND TELL: A giant panda bear is really a member of the racoon family.