Ghost 6.15 was released with a security fix for an XSS vulnerability in the portal.
Bad actors are now aware of the vulnerable, but no new Docker image is available to install with the fix. A fix is being worked out here, in a third-party repo:
It would great if the Ghost team could check that security fixes are going to build and release with Docker in a timely manner so self-hosters aren’t left exposed.
The last time I looked, the last docker update is at least 7 days ago :( Update: Docker updated 3 hours ago.
Update #2:6.14.0 is the latest version available to Docker Hub still.
Yeah, it would be nice to have docker hub update a little faster, or have a “nightly” tag or something. I’ve been using that method for the past few years and its always like a week behind. Its nice for if there might be something broken in a specific release so you dont get the bleeding edge but for vulnerabilities it kinda sucks.
This is about more than just timeliness, it’s about:
Ghost team not testing themselves if the Docker image they are promoting works before a release is made, which can leave self-hosters vulnerable
It’s about about security in general.
For more than a year, there’s been an alternate, hardened image available that has fewer potential vulnerabilities detected. Today, the published Ghost 6.14 image published has 3 critical vulns detected and 35 “high” vulnerability. My job involved remediating such vulns, and organizations that take such vulns seriously have policies like dealing with critical vulns within 24 or 48 hours and high severity vulns within a week or two.
The alternate approach is a smaller, hardened image addresses about half of these vulns without modifying Ghost itself– solely by using best practices in how the Docker image is constructed:
Ghost could be helping protect the ecosystem by building or promoting more secure image.
In the “Ghost-dev” Dockerfile in the team’s repo, ghost-cli is used to build their image– a complex dependency which is used both the official and the hardened “ghost-on-kubernetes” image. The promoted images could be further improved by dropping the ghost-cli dependency. According to the original bug report about this, it was problem in a sub-dependency of ghost-cli that triggered the failure of the 6.15 image to automatically build. Eliminating ghost-cli as a dep would eliminate that entire class of errors.
Understood, but the Ghost Image from Docker is used by Ghost in the official compose.yml file in the official ghost-docker repo, which is recommended to used in the official Docker installation instructions:
So if you follow the official guidance for installing Ghost using docker, you end up running this third-party maintained image, which has roughly twice as many detected security vulnerabilities as the “ghost-for-kubernetes” third-party Ghost image.
Ghost has their own Docker Hub account and publishes several images, including one that appears to be published through automation, but none of them are for the Ghost software itself:
I would like to add my support to this: Ghost needs improved Docker support. I understand that Docker support is in “preview”, but if it’s being promoted as a hosting option, it should get proper security maintenance.
I think it’s worth to mention this issue here, about security concerns for Docker Hub Ghost image:
TLDR; they find the vulnerabilities reported as either false-positives, or not related with docker image itself.
And last incident that blocked them to release new version was also a potential security flaw, because of the a nested NPM repository used a git repository as the dependency. But unluckily that release was also fixing another security issue.
Those aside, I would also like to have a Docker build right inside Ghost repository, and an automated GitHub build immediately with a version release.
It looks like Node.js had a similar situation recently, where their OCI images were updated promptly after a security release:
One of their core contributors posted that this merited a post-mortem review, and they are working an updated process to prevent it from happening again. Well done.
Ghost has again publicized a vulnerability in their software without a published Docker image without a published Docker image which contains the fix. Ghost has published 6.19.1 with a SQL injection fix, but the most recent Docker Official Image is at 6.18.2.
After this happened last time, I started collaborating with @ngeorger on a more secure alternate image and there’s now one that he created and I’ve successfully tested with 6.19.0. Perhaps he can push a 6.19.1 release soon.
Keep an eye out here, and look for releases with a -docker suffix. This is very new, and trying it out on a dev site is recommended!
I just submitted a patch to better document the new container option here:
As I mentioned there: “If you are moving from the Docker Hub image and don’t want to change the ownership of all your files, you can continue to use the same user with this image by specifying --user 100:1000 on a docker run line or updating a compose.yml file where you set image: to also set user: 1000:1000"
I submitted a second patch to start down the path of having these alternate images automatically published when Ghost makes a new release.
The Dockerfile is linked below if you wish to inspect it. Note my comments above about setting the user explicitly to 1000:1000 for compatibility with existing Ghost installs and testing it first on a dev site, or waiting for some other people to post their test results here.
For example, I mount my config file into the container. This has not been tested much or at all for setups that configure using exclusively env vars.