Security vulnerability in #Drupal contrib module puts 120000 sites at risk(drupal.sh)
drupal.sh
Security vulnerability in #Drupal contrib module puts 120000 sites at risk
http://drupal.sh/vulnerable-drupal-contrib-module-puts-120000-sites-at-risk
32 comments
Looking at the source it took me < 5 minutes to find the actual vuln =/. Drupal saying "Just migrate away" is not the correct way to handle this disclosure. Some people can't switch immediately. A patch should be made available, and the module should be depreciated. Does Drupal have a way to update modules easily? If not, there should be...
> Some people can't switch immediately. A patch should be made available, and the module should be depreciated
Maybe that's what should happen, but it's not what will happen.
The module is unmaintained. Who do you suggest should do it? Will you? If not then you're just demanding that work should be done somewhere, by someone else, without providing any path or resources for it. That's just not how freely contributed and shared labour works.
It's a risk you take on when you use that free resource, and why it matters to contribute back to the ecosystem that you're using free of charge. Frankly, if you've been using the freely available module for this long then you're already ahead of where you were before.
"This software is broken so you shouldn't use it" is absolutely a perfectly reasonable solution to the problem, and nobody owes you anything more.
Maybe that's what should happen, but it's not what will happen.
The module is unmaintained. Who do you suggest should do it? Will you? If not then you're just demanding that work should be done somewhere, by someone else, without providing any path or resources for it. That's just not how freely contributed and shared labour works.
It's a risk you take on when you use that free resource, and why it matters to contribute back to the ecosystem that you're using free of charge. Frankly, if you've been using the freely available module for this long then you're already ahead of where you were before.
"This software is broken so you shouldn't use it" is absolutely a perfectly reasonable solution to the problem, and nobody owes you anything more.
> The module is unmaintained. Who do you suggest should do it? Will you?
Yes. I am contacting the security team and working on a patch already. The page mentions someone is currently working on the issue already however.
> "This software is broken so you shouldn't use it" is absolutely a perfectly reasonable solution.
I don't completely agree. If it's unmaintained, new installations shouldn't use it, totally agree. That doesn't help the 120K installations which are using the plugin though. It may take more time to impedance match apis, rather then fixing the security issue.
Yes. I am contacting the security team and working on a patch already. The page mentions someone is currently working on the issue already however.
> "This software is broken so you shouldn't use it" is absolutely a perfectly reasonable solution.
I don't completely agree. If it's unmaintained, new installations shouldn't use it, totally agree. That doesn't help the 120K installations which are using the plugin though. It may take more time to impedance match apis, rather then fixing the security issue.
Same. Took hardly any time to see the SQL injection. I wonder how many more of these there are on older installations using modules that are no longer actively maintained (Hint: probably lots. Code quality has come a long way since the early days of Drupal.)
As someone who used to host many Drupal installs - all of them.
The joke around the ops/security team was Drupal is a remote shell with a bonus CMS attached to it.
The joke around the ops/security team was Drupal is a remote shell with a bonus CMS attached to it.
When was it, what versions of Drupal?
8 ended up as a massive rewrite to replace all the key parts with Symfony components.
I've always used this joke for Wordpress... a remote shell with a blog attached to it.
> Took hardly any time to see the SQL injection.
You sure you saw it correctly? Concatenation of hardcoded variants (poor-mans query builder) doesn't make an injection.
You sure you saw it correctly? Concatenation of hardcoded variants (poor-mans query builder) doesn't make an injection.
I saw that one too, I think it is something in the node_references auto_complete menu task. To lazy to test, I've got plumbing work to do.
All I'm seeing is a missing db_like which means a user can search for "%foo%bar%" instead of just "foo%bar". This is not a SQL-injection, nor a relevant issue.
The problem is in that function though. It is missing a condition for publication status. Titles of unpublished nodes should render for some users, but not all.
The problem is in that function though. It is missing a condition for publication status. Titles of unpublished nodes should render for some users, but not all.
Winner winner chicken dinner, https://www.reddit.com/r/drupal/comments/66bw8l/references_i...
> Drupal is known for it's large number of community contributed modules that add functionality to the bare bones core system.
No, it's known for its ridiculous number of security issues and sloppy code :/
No, it's known for its ridiculous number of security issues and sloppy code :/
Drupal is easy to criticize, but its handling of security issues and its code quality aren't the two places I'd start. They're actually two of the strengths of the project.
You're missing a /s there.
I've seen worse, way worse, than Drupal Core.
That of course does not include Drupal modules - there is, similar to the Wordpress ecosystem, the really bad stuff.
That of course does not include Drupal modules - there is, similar to the Wordpress ecosystem, the really bad stuff.
But that's the whole problem right there. Such a plug-in architecture with every Tom, Dick & Jane writing modules that are loosely vetted and deployed in the 100's of thousands is broken by design. There is no way a small review team focused on security will be able to audit what 1000's of dedicated lesser gods produce.
I can see the advantage of it, you just focus on the core and let the world take care of its own problems but you end up with nearly every site being critically dependent on a couple of obscure modules that will not get the attention they need until it is much too late. This coupled with Drupals nasty habit of obsoleting everything every couple of year (I hear they are changing now) and you're set up for disaster.
So even if Drupal Core is not all that bad it is never just Drupal Core.
I can see the advantage of it, you just focus on the core and let the world take care of its own problems but you end up with nearly every site being critically dependent on a couple of obscure modules that will not get the attention they need until it is much too late. This coupled with Drupals nasty habit of obsoleting everything every couple of year (I hear they are changing now) and you're set up for disaster.
So even if Drupal Core is not all that bad it is never just Drupal Core.
To get a module marked as "covered by the Drupal security team" it is required to go through a community code review.
Yes, but that's backwards. There are many many modules that don't have that stamp but that are distributed via the site and besides I strongly believe that security is not something you just vet for after the fact but that should go in to the design of your product.
If you don't do that it becomes a 'find the last hole in the cheese' exercise and very likely there will be many holes that you don't find that way that would not have been there in the first place had the whole thing been designed from day one with that in mind.
On the whole I think 'let amateurs build it and experts vet it' is better than just 'let amateurs build it' but it doesn't come close to 'let experts build it and experts vet it'.
If you don't do that it becomes a 'find the last hole in the cheese' exercise and very likely there will be many holes that you don't find that way that would not have been there in the first place had the whole thing been designed from day one with that in mind.
On the whole I think 'let amateurs build it and experts vet it' is better than just 'let amateurs build it' but it doesn't come close to 'let experts build it and experts vet it'.
Which is pretty easy to pass, you just have to follow the coding standards.
And not have any (glaring) security flaws.
This I can agree with. The community frowns upon selling modules. This is reflected by the official repository offering no option of purchasing modules, no marketplace. Contributors only make money by being sponsored by hosting sites like Acquia, where usually they're making modules /for/ them. This of course makes Drupal unnattractive for more advanced functionality. But, single developers still try to create that functionality anyways, even if its something that needs constant work and usual updates. This then understandably falls to the way side because life. Some things just need business behind them, they can't survive on openness alone.
Also: https://www.lullabot.com/articles/why-paid-drupal-modules-fa...
Also: https://www.lullabot.com/articles/why-paid-drupal-modules-fa...
Drupal is GPL, so a module written specifically for Drupal must always be redistributable under GPL as well since it's a derived work. That places a natural limit on the feasibility of module purchases, since anyone could buy it and then mirror it for free.
The correct answer here is that if you don't like Drupal's free & community-focused development model, you're likely better off switching to some off-the-shelf software. Alternatively, you can pay a consulting company to maintain the module, which is how many of them get written anyway (and then given away for free). So if you focus on modules with commercial backing, you've got a pretty close approximation without giving up GPL freedoms.
The correct answer here is that if you don't like Drupal's free & community-focused development model, you're likely better off switching to some off-the-shelf software. Alternatively, you can pay a consulting company to maintain the module, which is how many of them get written anyway (and then given away for free). So if you focus on modules with commercial backing, you've got a pretty close approximation without giving up GPL freedoms.
If you think going non-free with the modules would help you should take a look at the codebases of some of the most popular premium Wordpress modules. You'll find much worse than in a popular Drupal contrib module.
> But that's the whole problem right there. Such a plug-in architecture with every Tom, Dick & Jane writing modules that are loosely vetted and deployed in the 100's of thousands is broken by design.
Wait, are you talking about npm or Drupal? (only kind of kidding)
Wait, are you talking about npm or Drupal? (only kind of kidding)
That actually is a really good point about packages on NPM, or rather the culture of a 'package for everything.'. All it would take is somebody to lose their github account or go rogue, for one popular package that requires their package to also be compromised, and then hundreds to thousands of sites are silently vulnerable.
Seriously. A standard ES6 JS project will run you to actual hundreds of packages. Thats a huge attack surface.
Seriously. A standard ES6 JS project will run you to actual hundreds of packages. Thats a huge attack surface.
This can be said of every CMS ever that isn't designed for very specific cases. Many would argue Wordpress is significantly worse and a massive mess. Atleast Drupal 8 tries to standardize and use good standards. If you know a better CMS out there, or any specific current problems with drupal 8, lets hear it.
One reason why I prefer Wordpress is that I can pretty much build anything I want with just 'core' and a very small number of plugins (mostly Advanced Custom Fields, which has a paid version and quite actively developed).
With Drupal, on the other hand, I've always had to install a whole bunch of contrib modules just to get the basic functionality I needed. Has that changed significantly since Drupal 6 and 7?
Am I underestimating how insecure Wordpress core is, even considering that the get the equivalent you'd need Drupal plus a whole bunch of modules?
With Drupal, on the other hand, I've always had to install a whole bunch of contrib modules just to get the basic functionality I needed. Has that changed significantly since Drupal 6 and 7?
Am I underestimating how insecure Wordpress core is, even considering that the get the equivalent you'd need Drupal plus a whole bunch of modules?
Drupal 8 now has views as a core module, which so far has allowed me to make custom fields for editors and allow them to relate the data entry with other entries or tags/taxomonies. Its the only CMS I've experienced so far that allows me to make data entry highly customized towards the content being added. I'm not sure what you're specifically looking at, but views is pretty much a big abstraction layer for the database, there's a lot you can do with it.
You need a whole bunch of wp modules to get to the same level has a Drupal 8 core install.
Title is: Security vulnerability in unmaintained Drupal contrib module puts 120000 sites at risk
(Emphasis mine)
(Emphasis mine)