
Drupal Remote Code Execution vulnerability exploited widely - velmu
https://drupal.sh/drupal-remote-execution-vulnerability-exploit-sa-core-2018-004
======
sakarisson
I work at a company specializing in Drupal services. In fact, it was one of my
coworkers who discovered the Drupalgeddon2 exploit. My opinion is that people
and companies should be careful with using any CMS. All of our customers have
a genuine need for using Drupal, but the truth is that for most companies,
there is no need for an outward facing CMS. If there is no user interactivity,
I strongly recommend to anyone to build their site to static HTML and serve
that if at all possible.

Maintaining a CMS is a lot of work. We all stayed up late last night patching
all our supported sites. I think it's worth it for companies to completely
outsource maintenance to specialized companies. These recent patches seem back
up that claim. I'd guess that the vast majority of unpatched sites are self-
maintained.

~~~
a012
> I strongly recommend to anyone to build their site to static HTML and serve
> that if at all possible.

Is there any products that support CMS as backend and automatically generate
HTML as frontend OOTB?

~~~
dberhane
I recommend gatsbyjs (react.js based static generator) and it has plugin for
Drupal and Wordpress.

Here is the location of the Drupal plugin:
[https://github.com/gatsbyjs/gatsby/tree/master/packages/gats...](https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-
source-drupal)

And the headless Drupal GatbyJS demo: [https://using-
drupal.gatsbyjs.org/](https://using-drupal.gatsbyjs.org/)

~~~
mattferderer
I really like Gatsby & static site generators, especially when hosted on
something like Netlify.

Have you used it with a Drupal or WordPress on a larger site? To do a
decoupled site, every time someone publishes a new article or a change, you
are going to have to do a ton of HTTP requests during build time for Gatsby
since incremental builds are not a thing yet. If you use the Drupal Paragraphs
module, that can really complicate things as well. The only way around this
with Gatsby that I can think of is to have Drupal create a repository of
static files that get incrementally updated. Then Gatsby could grab a
compressed version of this during build & create a new version of the site.

I would love to hear thoughts from anyone else though as I'm sure better ideas
must exist.

~~~
octalmage
I noticed this too. I wrote a WordPress plugin to trigger a TravisCI build
when I publish a post and this works great, but it takes 5 minutes or so to
publish a new version of the site. For me this isn’t a huge deal, although
waiting 5 minutes to fix a grammar issue sucks, but for some this is going to
be a bigger deal when they’re used to being able to make changes instantly.

I noticed that the Gatsby WordPress plugin hits every endpoint on your site to
build the graphql data store, you could probably modify it to just hit the
ones you need. Additionally I feel like there should be a way to do persistent
incremental builds. At least there should be a way to cache the graphql stuff.
Maybe a incremental webpack build plugin exists.

~~~
mattferderer
Incremental builds via Webpack being worked on. Gatsby is waiting on these -
[https://github.com/gatsbyjs/gatsby/issues/179](https://github.com/gatsbyjs/gatsby/issues/179)

------
vesinisa
I offer free hosting and administration for a non-profit's Drupal site. It has
been a wild month. A few weeks after the March RCE issue, Drupal security team
announced that the bug was being actively exploited in the wild. For the RCE
announced yesterday, they sent a heads-up on Monday about upcoming critical
security release. I was on stand-by and applied the patch within minutes of it
being released yesterday. And sure enough - it was still rated "Critical" when
I applied the patch, but within only a few hours the ongoing exploits had been
adapted to take advantage of this new RCE and the bug was re-assessed as
"Highly critical".

Kudos to the Drupal security team for their work. I bet it's not the easiest
codebase to work with, but at least the security team are doing their job
well.

------
Tharkun
My biggest gripe with tools like Drupal (& WP and other FOSS CMS like things)
is that updating them often seems to break things. You have a custom layout
and upgrade? Shit breaks. Have some custom plugins? Shit breaks. After the
first couple of updates, your client no longer wants to pay you to fix things
after an upgrade, so you stop upgrading. Inevitably a remotely executable flaw
is found, and you're now fucked.

~~~
shakestheclown
While I do agree, Drupal does publish just the patch for these critical
updates for both D7 and D8. You can patch an old version of the site pretty
quickly without upgrading or working back in the inevitable core hacks. Each
of the big 3 Drupal fixes have been maybe 30 lines of code across 3 or so
files, IIRC.

Now if they aren't willing to even pay for that minimal level of service I
have little sympathy.

~~~
Tharkun
There are so many people out there who pay someone 500eur/usd for a simple
drupal website, and then expect to pay maybe 50/year for hosting, but are
entirely unwilling to pay for anything else. After all, they can get dirt
cheap hosting or free wordpress sites all over the internet, so paying
anything at all makes them seem like a good customer.

You get what you pay for. Unfortunately, many of those unpatched websites end
up causing trouble for others...

------
orf
> Nowadays Drupal is mostly marketed as a robust enterprise tool for markets
> to hold critical data

Who markets it as this? That's utter madness!

~~~
jochung
This is what millions in enterprise funding gets you. A decade+ of sunk cost
fallacy.

~~~
pjc50
What are the alternatives in ""enterprise"" CMS, though? Would you rather use
Sharepoint?

~~~
setquk
When someone suggests an enterprise CMS, the usual best case outcome is to go
back to the requirements analysis and remove enough requirements until an
enterprise CMS is not required.

I've done my fair share of work on the things over the years and the outcome
has never been the best one for the organisation.

~~~
Angostura
Ah yes, training up people to handcraft html every time a new press release
needs to go up on the site, or a VP changes on thecabout us page. Not fun.

~~~
setquk
Hire someone to do it. Cheaper than an enterprise CMS is to run and/or
commission.

~~~
Angostura
Lets see, my Wordpress install running a well known theme, using Wordfence to
alert for plugin updates, with me keeping an eye on it cost about £2,000 to
set up and has ongoing costs of about £1,000 a year.

No. Its not cheaper to hire someone to hand-code the site and then hand-code
every change.

~~~
setquk
If you're doing that, just use wordpress.com. Wordpress is way out of scope
for the term "enterprise CMS".

~~~
Angostura
So we've gone from "there's no need for a CMS, write HTML flat files" to "Use
a hosted CMS" \- OK.

------
mvdwoord
I really need to take a day or so and stick those 10 odd static pages in a
jekyll theme to get rid of this ageing D7 site I am maintaining. This endless
stream of updates is getting very tiresome.

The price one pays for being somewhat lazy (and bad at designing websites).

------
fabian2k
Am I reading the announcement correctly, that only registered users on the
site can exploit this specific vulnerability?

The seriously scary part about the previous vulnerabilities like Drupalgeddon
was that _anyone_ could exploit them without having an account on the site.

~~~
egeozcan
There used to be many Drupal-based sites which offer anonymous registration.
Last time I worked with Drupal was 5 years ago so maybe the situation changed.

------
sam152
> To make matters worse for Drupal security records, the vulnerability is
> being actively exploited hours after the patch was released by the Drupal
> core team.

This is true for Drupal 7, but not for Drupal 8. Nothing in wild has surfaced
regarding SA-CORE-2018-004 for D8 yet.

------
mattferderer
A giant warning label should be required for Drupal, Wordpress & any CMS that
offers a large market of plugins.

"Plugins are dependencies that if not maintained actively, may cause you to
fall behind on updating the core CMS. Not keeping your CMS up to date will
crush your website if an emergency security patch comes out & you can't update
to it."

I get that this could be said with any framework or code base, but as someone
whose job is to update a couple Drupal sites, I've almost been burned on this
way to many times. Content editors rely on a plugin. That plugin isn't getting
updated as fast as it should & Drupal introduced breaking changes so the
plugin won't work with the new Drupal version. We have to hold back an update
until the plugin gets patched. Fortunately I had just finished updating our
sites before this security announcement.

The best advice I can give to anyone managing multiple Drupal sites would be
pick your plugins carefully, make sure you have a testing server, make sure
you can set aside some time each month to run updates & fix the many issues
created by those updates, and create integration tests.

------
lowry
It's ugly but I updated just a few minutes ago, although the patch has been
available for 16 hours. The thing is, `drush up` did not show available
updates for me yesterday, and I was hesitating between going to bed and
manually applying a patch. Finally, I went to bed.

It's a pity Drupal infrastructure was not up to the task of distributing
updates to everyone at the moment of announcement.

~~~
hannob
what you were probably missing is drush pm-refresh.

drush updates its information about the latest available versions only every
few hours. Which... in times of urgent severe vulns that need to be patched
immediately is probably something they should reconsider.

~~~
geerlingguy
Similarly, if you use Composer, it can cache things for up to 10-15 minutes.
Also, Drupal.org’s subtree split process takes 5-10 minutes to push out a new
core update to Packagist, so if you wait for the update using Composer it
could be 20-30 minutes.

The most reliable method is to use Git, Drush, or the patch plugin with
Composer to apply the patch immediately, and push it out to your servers. Then
update to the latest core version and push that out to your servers once it’s
ready.

The security team usually links to the raw patch file for each new version in
the CVE.

------
dpcx
Looking over the code pre-patch, can someone with more knowledge explain to me
how that allows RCE?

~~~
duiker101
more info here [https://research.checkpoint.com/uncovering-
drupalgeddon-2/](https://research.checkpoint.com/uncovering-drupalgeddon-2/)

------
ausjke
Being a Drupal user since 2000(yes, that's 18 years) I now am moving all my
sites to wordpress. Never liked Drupal 8 is the main reason.

That been said, Drupal 8 might be a good fit for large sites that needs
flexibility and customization, for most (smaller) projects though, wordpress
seems a better choice these days, its popularity proves that.

~~~
mattferderer
Have you tried Ghost or Netlify's CMS? I would highly suggest them for small
sites over Wordpress. I find Wordpress runs into many of the same issues as
Drupal.

~~~
ausjke
heard about both.

Ghost looks like more for the hosting service similar to wordpress.com. I want
to self-host, so it is not the best option.

a quick check did not reveal how Netlify does its CMS, e.g. post can be
public/private/user-access-by-permissions, note CMS means I can classify
various levels of access rights, i.e. content-management(instead of just
publishing). Most CMS are geared towards public viewing, which is what blog
does, but CMS should do more,

Drupal with its access module got CMS right(still not built-in though),
Wordpress is similar, default for public viewing, but you have plugin to
control each posts' access rights. I have yet to see an OSS CMS without the
need of modules/plugins to make it a true CMS.

~~~
mattferderer
You can host Ghost on your own but it doesn't have much for user access
levels.

Netlify offers something but I haven't used it -
[https://www.netlify.com/docs/identity/](https://www.netlify.com/docs/identity/)

------
jakeogh
Will formal verification reverse the trend of old root bugs as a law of
nature?

We applied the D6 patch immediately, 911b/admin/reports/status says 6.35. The
avg active acct age is >10y. Anon users can do nothing. Is there anything else
to fix? Moved to Drupal 04/2005.

What is the longest running D* site?

~~~
hannob
>Will formal verification reverse the trend of old root bugs as a law of
nature? >We applied the D6 patch immediately,

Formal verification can do nothing to help people who run software that's been
outdated and unsupported for several years.

~~~
jakeogh
IDK why you seem annoyed, Drupal is so far from formal verification it's
obviously a different subject... this bug didn't care what D version you were
on anyway. There are many advantages to staying behind the upgrade curve,
especially on simple software.

You can spend a bunch of time going from 6 to 7, or you can spend almost the
same amount of time going from 6 to 8. It's not like there are major features
the users need, most of the work goes into not breaking existing customization
they expect.

------
blue1
Is there a patch for drupal 6, as there was for SA-CORE-2018-002?

~~~
ar-jan
Yes: [https://github.com/d6lts/drupal](https://github.com/d6lts/drupal)

------
reza_n
Is there some pattern or rule you can put into Varnish/CDN/nginx to prevent
this??

~~~
Jgrubb
You really need a Layer 7 kind of thing to be able to inspect the actual
payload of the request. I don't think any of those can do that. You'd need an
actual WAF.

~~~
krehl
Cloudflare was able to protect against Drupalgeddon 2

[https://blog.cloudflare.com/keeping-drupal-sites-safe-
with-c...](https://blog.cloudflare.com/keeping-drupal-sites-safe-with-
cloudflares-waf/)

~~~
Jgrubb
That's a WAF layer though. I don't know of a way to do this with Varnish or a
straight CDN.

------
disiplus
there is this shit
[https://github.com/dreadlocked/Drupalgeddon2](https://github.com/dreadlocked/Drupalgeddon2)
that i saw in my logs.

how to report it to github

~~~
pfg
I'm not sure why you think GitHub ought to take down code for a proof of
concept.

~~~
disiplus
its not exactly proof of a concept, there is also a version that allows you to
execute anything "as in wget a backdoor" look at the code, with this code you
can execute anything at the target/victim.

hell, look right at the message when the target is vulnerable.

Good News Everyone! Target seems to be exploitable (Code execution)! w00hooOO!

~~~
pfg
Pretty much any non-obfuscated PoC that anyone could come up with for this
vulnerability would be trivial to adapt to run malicious code. This doesn't
really lower the bar for anyone, and as long as there's no malicious payload,
it doesn't seem legally or morally wrong.

(This is not to say that you couldn't end up in a situation where you'll spend
a few years and a truckload of money in a legal fight because you've released
something like this.)

------
irockzz
That's why i did't work on drupal after 2012..

~~~
tasqyn
what you work on then?

------
chrismorgan
I legitimately wish that there were procedures and infrastructures in place
for the core teams of things like Drupal to exploit such RCE vulnerabilities
themselves (finding installations by the standard means that the bad guys also
use) with a payload that applies a suitable patch to fix the vulnerability
(definitely in a very-cautious way, e.g. only if the entire file to be patched
matches an expected checksum), and then email the site owner if possible to
declare what has been done.

~~~
egeozcan
Good intentions but honestly, that would be a legal nightmare.

~~~
pantulis
Well, you could make it and opt-in service with all legal disclaimers applied.

~~~
chrismorgan
In that case it’s completely useless.

