
Drupal Contrib – Highly Critical – Remote Code Execution PSA-2016-001 - ElijahLynn
https://www.drupal.org/psa-2016-001
======
dergachev
Oh hey, Elijah! I found out about this HN post because my friend wrote to me
about it, so I guess you're doing a good deed for the community.

I want to note that these vulnerabilities are in 3 Drupal 7 contributed
modules:

 _RESTWS_ (we personally never used this, but it has 5k installs)

 _Coder_ (we use its scripts all the time, but install it only in Dev
environment, not in Drupal codebase. However, we did have a client with 3
projects running it, and they're patching it now)

 _Webform Multiple File Upload_ (we never used this, but it has 3k installs)

So for context, this isn't exactly "Drupalgeddon 2.0", but if you know someone
who uses Drupal 7, they should check if they're using these modules, and
update them.

~~~
pfg
Small addition re: Coder: It's not necessary for the module to be enabled in
order to be exploitable, it just has to be _somewhere_ in your document
root[1]. If you share the same code base between dev and production, you might
be vulnerable even if it's disabled in production.

[1]:
[https://twitter.com/drupalsecurity/status/753263548458004480](https://twitter.com/drupalsecurity/status/753263548458004480)

~~~
ElijahLynn
Thanks for posting that very important point about the Coder module. We were
mitigated by the fact we used Composer to install an internal distribution and
Coder was in our /vendor/drupal/coder directory, not inside docroot.

------
danso
Question from a non-Drupal dev here: this notice deals with third-party
modules that don't _sound_ like they'd be ubiquitous for deployments. But it's
in the PSA section in which has few posts overall, and seems to focus on
Drupal core. Am I underestimating the install base, or overestimating the
likelihood of 3rd-party modules having security holes?

(It doesn't seem that WordPress's security section concerns itself with plugin
flaws...because if it did, that's be a pretty busy section...)

Edit: Ok this I was also wondering: are these flaws a result of something
related to Drupal core?

[https://news.ycombinator.com/item?id=12088471](https://news.ycombinator.com/item?id=12088471)

Is it standard for Drupal to _not_ disable web access to disabled plugins? Or
is this notice for the rare edge custom deployments in which default
safeguards are disabled? How can a non-admin reach a disabled plugin
(nevermind execute it)?

~~~
pfg
New(ish) projects using popular PHP frameworks typically have all their code
stored somewhere outside of the web server's document root - there's usually
just a single PHP file in the document root that's responsible for
instantiating a front controller or bootstrapping the app in some other way,
with a .htaccess (or similar) file telling the web server to redirect all
requests to that file.

Drupal (and WordPress, etc.) come from a time where your entire code base
would live in the document root, so knowing the path to a .php file is often
enough to execute the script. While it would be possible to limit this with
something like .htaccess, it's error-prone, web server-specific, and can break
existing code in your ecosystem, so that's probably why it's not being done
consistently. Changing the code structure of Drupal in a way that would put
most of the code outside of the document root would similarly cause a lot of
work for the ecosystem and might make installation in typical shared web
hosting environments impossible in some scenarios - I've seen hosters who only
allow you to upload files straight to the document root, so there'd be no way
to use such a project with those plans. This is in essence just another case
of things going wrong because compatibility was prioritized over possible
security concerns, and I don't even want to blame them _too_ much for that,
given the usual outcry when backwards-incompatible changes cause work for
(plugin) developers in general.

------
jswny
Looks like a very small number of sites are affected (1,000 - 10,1000 out of
1.2 million total[1]). Nonetheless, it's a serious bug and to be safe it's
probably advisable to assume that your site is vulnerable if it is running
Drupal.

1:
[https://www.drupal.org/project/usage/drupal](https://www.drupal.org/project/usage/drupal)

------
jlgaddis
I am so glad I quit using Drupal years ago (due to its recurring security
issues, coincidentally) and "banned" it in our organization.

(Yes, I realize these issues are in third-party/contributed modules.)

~~~
ksenzee
If you found software to switch to that is free of security issues, I imagine
we would all be interested to know what it is.

~~~
hannob
While you can't make software perfectly secure you can make security updates
as easy as possible. Drupal is exceptionally bad at this. IMHO Wordpress does
the right thing with its auto updates. That still doesn't solve the problem
for plugins, but it's probably prevented a lot of hacked sites. I think a CMS
without an autoupdate functionality cannot be recommended for general use
these days.

~~~
fluxsauce
Drupal has a built-in update mechanism and it's been around for years.
Administrators receive update notifications via email, they're surfaced in the
status page, and there's a site-wide admin notification on every page when
there's a security release available.

You can update both core and modules (similar to plugins for WordPress) using
the web interface, which is included with core, or use a command-line
utilities like Drush for Drupal 7, or Composer in Drupal 8.

There's lots of very valid reasons to be critical of Drupal, but:

> Drupal is exceptionally bad at this.

I don't think that's accurate.

