Issues Updating Drupal Core from 8.5.1 to 8.5.3

Introduction

Another highly critical security advisory has been issued for Drupal.

A remote code execution vulnerability exists within multiple subsystems of Drupal 7.x and 8.x. This potentially allows attackers to exploit multiple attack vectors on a Drupal site, which could result in the site being compromised. This vulnerability is related to Drupal core – Highly critical – Remote Code Execution – SA-CORE-2018-002. Both SA-CORE-2018-002 and this vulnerability are being exploited in the wild.

I ran into two different issues when updating from Drupal version 8.5.1 to 8.5.3 using composer on a Drupal instance.

Issue 1: Cannot Allocate Memory

composer update
...
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 30 updates, 0 removals
  - Updating guzzlehttp/guzzle (6.3.2 => 6.3.3): The following exception is caused by a lack of memory or swap, or not having swap configured
Check https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors for details
                                                    

  [ErrorException]                                   
  proc_open(): fork failed - Cannot allocate memory 

I was able to fix the issue by following the link in the error message: https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors. Increasing the swap space fixed this issue.

sudo /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
sudo /sbin/mkswap /var/swap.1
sudo /sbin/swapon /var/swap.1

Issue 2: Nothing to install or update

composer update
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update

This was another trivial issue. The composer.json file was restricted the update from updating past version 8.5.1

composer prohibits drupal/core:8.5.3
drupal-composer/drupal-project - requires drupal/core (8.5.1)

Changing the require section in the composer.json from:

“require”:{
	

	"drupal/core": "8.5.1",

}

To

“require”:{


	"drupal/core": "~8.5",


}

This tells composer that it can update to the latest version of the Drupal core in 8.5.x.

composer update
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 1 update, 0 removals
  - Updating drupal/core (8.5.1 => 8.5.3):  Checking out b012f0ae51
Writing lock file
Generating autoload files
Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)> DrupalProject\composer\ScriptHandler::createRequiredFiles

Success!

Using Let’s Encrypt to Secure WordPress on AWS Lightsail

This tutorial is a slightly modified version of the tutorial on Digitial Ocean, but is modified to work specifically with Bitnami on AWS Lightsail. This tutorial will show you how to:

  1. Install Let’s Encrypt
  2. Generate TLS/SSL Certificate with Let’s Encrypt
  3. Configure Apache to use the TLS/SSL Certificate
  4. Configure Apache to only use HTTPS
  5. Update wp-config.php

Prerequisites

  1. A running Bitnami instance on AWS Ligthsail.
  2. A registered domain name configured properly for your Bitnami instance.

Step 1 – Install a TLS/SSL Certificate with Let’s Encrypt

Let’s Encrypt certificates are fetched via client software running on your server. The official client is called Certbot, and its developers maintain their own Ubuntu software repository with up-to-date versions. Because Certbot is in such active development it’s worth using this repository to install a newer version than Ubuntu provides by default.

First, add the repository:

sudo add-apt-repository ppa:certbot/certbot

You’ll need to press ENTER to accept. Afterwards, update the package list to pick up the new repository’s package information:

sudo apt-get update

And finally, install Certbot from the new repository with apt-get:

sudo apt-get install python-certbot-apache

The certbot Let’s Encrypt client is now ready to use.

Step 2 – Generate a TLS/SSL Certificate with Let’s Encrypt

First run the command below where example.com is your domain name for your website.

sudo certbot certonly --manual -d example.com

You should see the following results. Press Y and enter to continue.

-------------------------------------------------------------------
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
-------------------------------------------------------------------
(Y)es/(N)o: Y

Then you should see a similar result as below.

-------------------------------------------------------------------
Create a file containing just this data:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

And make it available on your web server at this URL:

http://example.com/.well-known/acme-challenge/MY-LONG-RANDOM-FILE-STRING

-------------------------------------------------------------------

Open another shell connection to your instance to complete the instructions.

sudo mkdir /opt/bitnami/apps/wordpress/htdocs/.well-kown

sudo mkdir /opt/bitnami/apps/wordpress/htdocs/.well-kow/acme-challenge

Create the requested file and add the data to it, replacing MY-LONG-RANDOM-FILE-STRING with the randomly generated string they gave you.

sudo vi /opt/bitnami/apps/wordpress/htdocs/.well-kown/MY-LONG-RANDOM-FILE-STRING

Once you have created that file with the data, go back to your original shell connection and press enter. Verify that the example.com directory exists in /etc/letsencrypt/live. To do this you need to be root.

sudo su

Change to the directory.

cd /etc/letsencrypt/live/

List the contents of the directory.

ls
root@ip-XXX-XXX-XXX-XXX:/etc/letsencrypt/live# ls
example.com

Exit the super user mode.

exit

Your certificate should have been successfully generated.

Step 3 – Configure Apache to use the TLS/SSL Certificate

Navigate to the bitnami configuration directory for apache.

cd /opt/bitnami/apache2/conf/bitnami

Open the bitnami.conf file for editing.

vi bitnami.conf

Change the SSLCertificateFile and SSLCertificateKeyFile directives to point to your newly generated certificates.

SSLCertificateFile "/etc/letsencrypt/live/example.com/fullchain.pem"
SSLCertificateKeyFile "/etc/letsencrypt/live/example.com/privkey.pem"

Restart apache.

sudo /opt/bitnami/ctlscript.sh restart apache

Step 4 – Force HTTPS

Add the following to the top of the /opt/bitnami/apps/wordpress/conf/httpd-prefix.conf file:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/(.*) https://%{SERVER_NAME}/$1 [R,L]

Restart apache.

sudo /opt/bitnami/ctlscript.sh restart apache

Step 5 – Update wp-config.php

Make sure you update WP_SITEURL and WP_HOME in /opt/bitnami/apps/wordpress/htdocs/wp-config.php

define('WP_SITEURL', 'https://example.com/');
define('WP_HOME', 'https://example.com/');

Mount SFTP over SOCKS Proxy in OSX with Cyberduck

I can only access certain servers at work over SSH if I am using a machine with a certain static IP address. I wanted to be able to mount the servers file space using SFTP on a Macbook Air when I am either at home or at  a remote location. I investigated a lot of different ways to accomplish this with little success. After a lot of trial and error I was able to create a Socks proxy to my work machine using ssh and then mount the server file systems by using Cyberduck and enabling the use of the socks proxy.

Network Diagram
Network Diagram

First, I needed to create the socks proxy. In order to do this I had to SSH into my work machine and dynamical forward a port 8080. You may forward any port that is not being used greater than 1024. This will send any traffic on that port through the tunnel and out of the machine that you are connected to.

ssh username@192.168.1.1 -D8080

After I have created the SSH connection with the dynamic port forwarding, I enabled the socks proxy in OSX Network Preferences -> Advanced -> Proxies. Check the “SOCKS Proxy” box. Then, set the “SOCKS Proxy Server” to 127.0.0.1:8080. Finally, add the IP or Domain of the machine that has the SSH connection to the “Bypass proxy settings for these Hosts & Domains” box.

OSX Socks proxy settings
OSX SOCKS Proxy Settings

Now enable the proxy in Cyberduck. Go to “Cyberduck” -> “System Preferences” -> “Connection” and check the box that says “Use system proxy settings”.

Cyberduck system preferences for proxies
Cyberduck system preferences for proxies

Now every connection in Cyberduck will flow through your SOCKS proxy that you set up so you can mount the remote server file system over SFTP.

Using Twitter API with a Proxy in WordPress

1280px-Reverse_proxy_h2g2bob.svg

I was launching a new WordPress website at work that was developed by an outside agency. This site was using twitteroauth built into the theme to access the twitter API. Where I work all the web servers are behind a firewall with a strict whitelist for all incoming and outgoing connections besides the incoming HTTP and HTTPS requests. This makes it difficult to access the twitter API because it could be a different IP address every time. To solve this issues my work provides a proxy server to make requests out to. So my research began.

WordPress began to provide configuration settings in the wp-config.php file for them (http://wpengineer.com/1227/wordpress-proxysupport/):

define('WP_PROXY_HOST', '192.168.84.101');
define('WP_PROXY_PORT', '8080');
define('WP_PROXY_USERNAME', 'my_user_name');
define('WP_PROXY_PASSWORD', 'my_password');
define('WP_PROXY_BYPASS_HOSTS', 'localhost, www.example.com');

Unfortunately, the developers built the twitter api into their theme so I had to manually track down the API calls to modify them to use the WordPress configuration settings. In the twitteroauth.php file in the themes folder I was able to add three lines to the
curl_setopt parameters to function http (http://php.net/manual/en/function.curl-setopt.php):

curl_setopt($ci, CURLOPT_PROXY, '192.168.84.101');
curl_setopt($ci, CURLOPT_PROXYPORT, 8080);
curl_setopt($ci, CURLOPT_HTTPPROXYTUNNEL, 1);

Everything worked once I added those three lines.