Slashdot Mirror
Drupal Update Process Flawed By Multiple Bugs (softpedia.com)
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.
Drupa teams learn from wise asian cows. They just shake their tail, and all those nasty bugs fly away. Mooooo!
Derpal is Wordpress for business / education. It's what you use to host a site when you need some bullshit on the web quickly, you don't care about it being good or secure, and you want someone else to manage the content. (Note that they'll still come to you for help for every single thing.)
Drupal is broken you say? And the developers let boneheaded bugs fester in the codebase for years before deciding to (maybe) think about fixing them?
Interesting. Remind me, what is Drupal again?
Of course. Why doesn't that surprise me?
But only once I discovered that "Steph the Geek" was into Drupal. Before that I was ambivalent, but she's so lame it skewed my opinion.
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.
news for nerds
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 testing after an update. Just use automatic CI testing (Behat, etc.) to ensure the site holds up after an update. travis-ci.org tied to a Github repo for automatic test execution with each new commit is your friend.
Finally, if you aren't using version control (such as Git) for professional web development - Drupal or not - that's irresponsible, unprofessional, and dangerous. It's like driving drunk without insurance in someone else's car. Sooner or later it's gonna catch up with you - and if you're managing a web site that does more than serve a simple brochure site, that car crash is not gonna be pretty.
Seriously - get with the times. Use Git. Learn "git clone", "git init", "git add somefile.php", "git commit", "git push", "git fetch" (and "git pull"), "git diff", "git log" "git stash", "git reset --hard HEAD~1 (or the commit's hash)" (and what --soft and --mixed mean vs. --hard), "git revert", and you're ready to do 99% of anything you'll ever need to do with Git. It's just not that hard or scary. Really. If you want ridiculously hard, try using the superfluous, bullshit Database API in Drupal 7 to anything beyond a SELECT query. Talk about a waste - was db_query() with sanitation really not good enough, Dries? Backdrop got that part right... :)
1. Drupal doesn't have an autoupdate process; all updates have to be done manually
2. Only an idiot updates a live production machine before testing any and all updates on a dev machine first
3. Once an update is tested you update by uploading from your dev server to the production server so there's no middle man
4. WTF is with this stupid FUD and the modded up idiot that knows nothing about Drupal (looking at you DNS-and-BIND)?
Drupal might be nice if you like snapshot "mine looks like his, looks like the default" websites, but that's what it amounts to. Drupal is a POS. If you want to make any non-standard change, you have to take what is already there (oh noes, never modify the original), make a copy, then hack on that. And if what you want isn't already there, then you are fucked. Been there, done that. Next come the weenies saying "but its all there!" And no its not. I spent a lot of time debugging a druapl book teaching drupal. The API had changed massively, and no one gave a shit about having something that works. Now its kinda wacked: I had built a system so that I could just drop in a new version of Drupal, and I wouldn't even have to decompress the file for the upgrade and all the extras to be upgraded (and I remember so-called 'developers' having a hard time with that. But its a poorly documented, piece of shit. Development took about 20 times a long to do even simple things as any other kind of site. "Oh, but its enterprise" and my response is "so is anything else". Its all bits flowing, and the databases are common, and the backend and the flow of bits isn't this, this is just site content, and everyone else does it too, and just as easily. The others can be as advanced (actually more so), but Druapl is crap. Why would anyone build a highway with hairpin turns and steep grades on a flat plane? But Drupal insists its the right way to go. Stupid.
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.
Most enterprise Drupal installations (as opposed to small businesses or individuals who happen to have Drupal sites) use the following process to update:
- Have a local build script (typically using drush)
- Build locally
- Commit to git repo
- Push update to the server
Unless I'm mis-reading the article, I don't believe this process is effected by the bug described.
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...