My colleagues and I in the Drupal Security Team recently became aware of a Zero Day RCE vulnerability in Ghostscript. This was later assigned CVE-2021-3781.

At least one viable Proof of Concept (PoC) was made public not long after the Zero Day which illustrated Scalable Vector Graphics (SVG) handling in Imagemagick being used as an attack vector.

Drupal core doesn’t use Ghostscript directly, but it’s fairly common for Drupal sites to use Imagemagick in some form.

As such, we began to look at how an attacker might try to exploit the Ghostscript vulnerability via SVG and Imagemagick on a Drupal site.

Our goal in such an investigation is to determine whether it would be sufficiently easy, with a common Drupal configuration, that we ought to issue a Public Security Announcement (PSA) warning Drupal users and providing any mitigation steps they might be able to take until an upstream fix was available.

Here’s a quick write-up of some of the investigation I did.

We’d determined that SVG is not in the default list of permitted image extensions in Drupal.

However, the PoC write up showed Imagemagick being tricked into parsing an SVG with a fake jpg extension.

I verified that in Drupal 9 the built-in file type detection prevented a malicious SVG from being smuggled into an upload with a permitted file extension.

Drupal 7 core by itself doesn’t have this protection, although modules are available that add e.g. mime-type sniffing such as https://www.drupal.org/project/mimedetect.

How might an attacker try to take advantage of this?

Drupal core has built-in support for “image styles” which can perform preset transformations on uploaded images. For example, a thumbnail image is often prepared to show in previews of articles.

So a Drupal site which uses Imagemagick to handle image processing (GD is the default in core but alternative “image toolkits” are available) might be exploited if an attacker could upload a malicious SVG and have the site try to perform an image manipulation on this, such as resizing it to prepare a thumbnail. This sort of functionality is quite common – for example – when a newly registered user uploads a profile picture. That would make a good target for an attacker.

I ran through what happens if you smuggle a malicious SVG masquerading as a permitted image type into a D7 upload field. As Drupal tries to record the metadata about the image, it makes a series of API calls which end up invoking image_get_info() which in turn calls image_toolkit_invoke('get_info', $image).

At that point both the default GD and the alternative Imagemagick toolkits call PHP’s built in getimagesize() on the image. If the image in question is actually an SVG, this will typically return FALSE.

That means that Drupal will not attempt to perform a transformation on the image – for example to create a thumbnail – because it has not been able to derive the image’s metadata including the dimensions of the original.

Even on a site which has explicit support for the uploads of SVG files (and you might argue that would be quite unusual for e.g. user profile pics) – because of the nature of SVGs – Drupal’s default behaviour of deriving some image metadata and then deciding whether image transformations should be performed doesn’t work like it does for e.g. jpg and png files.

At least one popular SVG contrib module tries to derive an SVG image’s dimensions by parsing it as XML, but the malicious files produced by the PoC are not correctly formed for this.

It doesn’t really make sense to try and run an SVG through Imagemagick’s convert to create a thumbnail or other derivative of a different size – that’s sort of the whole point of Scalable Vector Graphics.

This investigation had focused on Drupal 7, but it looked like Drupal 9 would be – if anything – better protected because of its built-in file type detection.

One popular configuration to support SVGs in D8/9 uses a vendored library to validate the XML and rejected the PoC’s malicious SVG during upload validation.

There are a handful of different ways (as is often the case in Drupal) to set up SVG support in Drupal 9, but in one discussion about SVG support, phenaproxima (one of the media module’s developers) stated:

The Media module itself has no opinion about SVG images. The Image module, on the other hand, doesn’t normally allow SVG to be uploaded into any image field, due to the various security and integration issues (i.e., image styles).

So it really didn’t look great for our potential attacker trying to exploit Drupal’s image styles (automatic image transformations) via SVG and an Imagemagick toolkit to take advantage of the Ghostscript Zero Day.

As it looked like it wouldn’t be easy to exploit this in what we’d consider a common configuration of Drupal, we decided against issuing a PSA.

This is not to say it’s inconceivable that the vulnerability could be exploited on a Drupal site out there somewhere, but it would likely be considered an “edge case”.

It’s also possible that I got some of this wrong. If you know of any significant details I missed which mean that exploitation might be easier or more likely than my analysis suggested, please contact me or the Drupal Security Team privately in the first instance. We will credit any researchers who provide information that leads to us issuing a Security Advisory.

Thanks to Greg Knaddison (greggles) for (suggesting and) reviewing this post.