
“Drupalgeddon2” touches off arms race to mass-exploit powerful web servers - jonbaer
https://arstechnica.com/information-technology/2018/04/drupalgeddon2-touches-off-arms-race-to-mass-exploit-powerful-web-servers/
======
hippich
Patches for people who cannot easily upgrade code base:

D5: [https://www.drupal.org/files/issues/2018-03-28/sa-
core-2018-...](https://www.drupal.org/files/issues/2018-03-28/sa-
core-2018-002-d5.patch)

D6: [https://www.drupal.org/files/issues/2018-03-28/SA-
CORE-2018-...](https://www.drupal.org/files/issues/2018-03-28/SA-
CORE-2018-002.patch)

D7:
[https://cgit.drupalcode.org/drupal/rawdiff/?h=7.x&id=2266d2a...](https://cgit.drupalcode.org/drupal/rawdiff/?h=7.x&id=2266d2a83db50e2f97682d9a0fb8a18e2722cba5)

D8:
[https://cgit.drupalcode.org/drupal/rawdiff/?h=8.5.x&id=5ac87...](https://cgit.drupalcode.org/drupal/rawdiff/?h=8.5.x&id=5ac8738fa69df34a0635f0907d661b509ff9a28f)

~~~
Falkon1313
And if the codebase is on PHP 5.x, then depending upon what modules and custom
code you have, the security fix might break some things. There's a bugfix
patch to the security patch at:
[https://www.drupal.org/files/issues/2018-03-29/SA-
CORE-2018-...](https://www.drupal.org/files/issues/2018-03-29/SA-
CORE-2018-002-bugfix1.patch)

That's the D6 version, but same concept would apply to other versions.

------
Roritharr
This, to me, is the main reason why it's a bad idea to host and maintain a
presence with a CMS yourself. Most likely you are not an entity that has the
capabilities necessary to do so, neither are most of the Hosters that even
offer "managed Drupal/WordPress/... Hosting".

It takes a relatively large team to reliable shield software as complex as
modern CMS from abuse and the mitigations have to be employed so timely that
one cannot wait until this is high enough on someone's to-do list that has to
do this for 10 different CMS.

~~~
lsc
Seems like the right thing to do for most CMS type situations is something
that generates the site offline... and only uploads a static site to the web.

Something like jekyll or something.

~~~
jmknoll
I'm a big fan of Jekyll (and more recently, Gatsby), and I think you're
correct in saying that in most cases where a CMS is used, a static site
generator would be a better option.

However, I see a couple of problems standing in the way of more widespread
adoption of static site generators:

1) I've never seen a static site generator that non-technical users felt
comfortable with. Programmers like terminal interfaces. Your average user in
2018 has probably never opened the terminal.

2) Possibly even more significant, I don't think the people making the choice
to use a CMS for a simple business-info or blog site are aware of the trade-
offs that they're making, or of the benefits that a static site will provide
down the line. For a lot of small business owners I've spoken with, Wordpress
is basically synonymous with "web presence."

I wonder if there's a market for a web-based GUI like what Wordpress provides,
but which runs jekyll under the hood and uploads the files to s3 or something
like that. Is this what companies like Squarespace and Wix do?

~~~
hunvreus
The first point is why I built Jekyll+ [1], which I initially built for the
new Starbucks' website [2] (which runs on Jekyll). It supports multilingual
content and we're now adding a whole bunch of new features (you can check the
TODO list in the README [3]).

We also have a pretty neat solution for site generation/hosting (JekyllPro)
which is rolling out next month.

Using these two, none of the contributors realize they're using Jekyll. It's
not as user-friendly as Squarespace, but it's pretty darn good.

1:
[https://github.com/Wiredcraft/jekyllplus](https://github.com/Wiredcraft/jekyllplus)

2: [https://wiredcraft.com/blog/the-new-starbucks-cn-website-
bol...](https://wiredcraft.com/blog/the-new-starbucks-cn-website-bold-mobile-
first-and-hyper-personalized/)

3:
[https://github.com/Wiredcraft/jekyllplus#todo](https://github.com/Wiredcraft/jekyllplus#todo)

~~~
bloopernova
Just wanted to say that I really admire Jekyll, and Jekyll+ looks very nice
too.

------
velmu
The Drupal security team is doing a great job, but "abandoned" installs of
similar tools are everywhere. Even high profile users of Drupal like Cambridge
Analytica* continue to use a vulnerable version. Though their install is not
exploitable due to disabled features, AFAIK.

* [https://drupal.sh/cambridge-analytica-drupal-vulnerable](https://drupal.sh/cambridge-analytica-drupal-vulnerable)

~~~
pmlnr
This is why WordPress rolled out a built-in automatic updater.

~~~
stephenr
Sure, run arguably the worst written php in the world, with permission to
overwrite itself.

What could go wrong.

~~~
hannob
> What could go wrong.

Well, after several years not much went wrong. There was a single case where
the updated broke the update process, thus forcing users to a single manual
(still one-click) update. I.e. the worst that happened is that in one instance
wordpress was as bad as any other major CMS by not having working automated
updates.

What went right however is that probably thousands of wordpress infections
have been prevented by automated updates that work 99% of the time.

Wordpress surely isn't perfect, but the fact that they have automated updates
that work most of the time means they're more secure than any of their major
competitors for now.

~~~
snowwrestler
> Well, after several years not much went wrong.

You're talking about whether something has gone wrong with the auto-update
system, specifically.

However, the parent comment was referencing the risk inherent in granting a
PHP application write permissions on its own files. Doing so means that almost
any exploit in the application can result in persistence, because malware can
be written into (hidden in) core Wordpress files. You would not necessarily
know how often this happens, because it happens to individual sites.

The Wordpress community decided that the risk of not patching quickly
outweighed the risk of allowing Wordpress to write its own files. I happen to
agree with them; unpatched vulnerabilities are like candy for script kiddies
and fall easily to automated attacks. And most people running Wordpress are
not sophisticated.

That said, for teams that are on the ball about managing updates, running
Wordpress with locked down filed/directory permissions is definitely more
secure.

------
Firerouge
Is it accurate to say that as long as comments are disabled globally Drupal
sites are not vulnerable to this exploit?

~~~
chx
The exploit is in file uploads. Nothing to do with comments. The first
published exploit pointed at user registration which had a profile picture
upload field.

The last time switching off comments helped (as far as I can remember but note
I only remember the more serious secholes) was 13 years ago and the only
reason _that_ wasn't called Drupalgeddon because barely anyone used it back
then and naming them wasn't in fashion (and we had two more RCE bugs the first
half of 2005 anyways before we kicked out the old XML-RPC library and replaced
it with a better one) ... but DRUPAL-SA-2005-002 was very, very long ago. And
while Adrian wrote form API around the same time for theming purposes, we ran
with it to avoid that kind of bug happening again. We? Or... just me? should I
take the blame? It was an ... emerging decision but a lot of it were on me. As
they years has passed, form API became frighteningly complex and a lot of that
is certainly on me, someone misused it and bam! Drupalgeddon2 . It makes me
sad but I do not feel guilty. I felt guilty for Drupalgeddon because that was
a silly one, more of a process fail than a technical one, this was not silly,
this was just too complex. Frankly, catching the bug in D7 was very near
impossible, whoever ported this code to D8 should've seen it because it
clearly violated the most fundamental form API principles but when you are
busy porting so much code, it slipped through the cracks. Just as Rachel said
for Drupalgeddon: I shouldn't feel guilty, others could've caught it too. And,
after all, I am out now so it has nothing to do with me any more. Or that's
what I am telling myself these empty, sad days and nights.

~~~
Firerouge
Thank you for your detailed and informative response.

This is the first I'd heard of you chx, you have quite a storied history
surrounding your untimely departure from Drupal.

If nothing else you sound like a great developer, and I hope you've found new
projects in the FOSS community which can benefit from your expertise.

------
DonHopkins
I'm taking down my old Drupal site and moving the content I care about to
Medium. But there are a lot of links out in the wild to the Drupal pages.

So I'd like to configure a bunch of redirects to bounce people from the old
Drupal urls to the new Medium pages.

Will I have to do it by hand for each URL I care about, or are there some
tools to help doing that, like scraping google or my logs for a histogram of
incoming links, to determine which ones matter the most?

I'd appreciate any links or suggestions about tools or techniques to migrate
out of a CMS like Drupal and redirect old links to the new pages. How to play
well with google and SEO, how to normalize the urls, what kind of redirects to
use, what nuances are there about which urls to redirect, etc?

~~~
PuffinBlue
What you're asking about there could amount to a fair amount of work and it
probably too much to fully answer in a comment reply so an alternative...

If you wanted to just do something quickly and then in slower time make the
finer adjustments you could simply spider and download your current site with
wget and then drop the resulting static html into Netlify.

It's free and I just did that with an old Wordpress site that I didn't want to
take the time to upgrade and deal with but needed to make secure right away.

I kept a copy of the Wordpress install to work with locally and the live site
now just returns static html hosted on Netlify that can't be attacked.

------
kostajh
Looks like there's a follow up patch, with another security release set for
this Wednesday.
[https://www.drupal.org/psa-2018-003](https://www.drupal.org/psa-2018-003)

