Hacker News new | ask | show | jobs
by kyled 3356 days ago
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...
3 comments

> 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.

> 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.

They probably don't want to get into the realm of maintaining user contributed modules.

They do offer an alternative (Entity Reference) and asked if anyone would patch or maintain the module. They also added a warning on the module's page.

Looks like someone is writing a patch already.
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.

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.

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.