Self-hosters left vulnerable to XSS vuln due to second-class Docker support

Developer help
,
21

I have shut down my site, rather than leave it vulnerable.

3 Likes
22

i appreciate those details but why are the maintainers just not updating the dockerhub as quickly?

23

The Docker Hub image maintainers are volunteers. They may be busy at work.

Depending on volunteers to be on standby at a momentā€™s notice is not a recipe for security. For critical vulns, itā€™s common for open source projects to privately coordinate with major packagers so that packages with fixes are available when the vulnerability is disclosed.

The situation can change if the exploit is known be in use in the wild. Then the priority may shift to getting a fix out in any form, so at least some people with know-how can patch their systems even if official packages are not released yet.

2 Likes
24

Should be Ghost team directly. Such a shame.

4 Likes
25

I disagree. We are a community because we want to support each other efforts.

Thanks a lot @markstos for alerting me, your collaboration spirit and your kind words. AdemƔs tu espaƱol es muy bueno!

1 Like
26

Hereā€™s public disclosure of the latest SQL injection vuln. @curiositry Note that it describes a temporary mitigation that can be implemented with a reverse proxy that you may have running in front of Ghost. An LLM could help with the specific syntax needed for whichever product you might be using a reverse proxy.

Impact

A SQL injection vulnerability existed in Ghostā€™s Content API that allowed unauthenticated attackers to read arbitrary data from the database.

Vulnerable Versions

This vulnerability is present in Ghost v3.24.0 to v 6.19.0.

Patches

v6.19.1 contains a fix for this issue.

Workarounds

There is no application-level workaround. The Content API key is public by design, so restricting key access does not mitigate this vulnerability.

As a temporary mitigation, a reverse proxy or WAF rule can be used to block Content API requests containing slug%3A%5B or slug:[ in the query string filter parameter. Note that this may break legitimate slug filter functionality.

4 Likes
27

More info on what this is waiting on here:

28

OK, so Iā€™m confused about why the Docker version is considered ā€œnot officialā€ when itā€™s listed as a preview in the official Ghost docs themselves:

IMO, if this is not managed by Ghost, Ghost shouldnā€™t be putting it in the docs. In the meantime, Iā€™ve taken down my website waiting for Docker to be up-to-date. Which isnā€™t a great look for me or for Ghost, frankly.

6 Likes
29

Looks like @tianon has reviewed and merged!

I can see thereā€™s a build in progress, here:

4 Likes
30

EDIT: While writing this it looks like there might be movement on the revised docker image, so if itā€™s available shortly, it may be best to wait for that.

Original post:

For my site, which does not appear to have integrations or other elements that use the following types of API requests:

Content API requests containing slug%3A%5B or slug:[

Iā€™ve kept my original Caddyfile{$DOMAIN}section at the top, except added the following under ${DOMAIN}, before the other rules that start with import snippets/Logging

        # GHSA-w52v-v783-gw97 mitigation:
        # Block Content API requests where the *decoded* filter contains "slug:["
        @ghost_slug_filter_block {
                path /ghost/api/content/*
                expression `{query.filter}.contains("slug:[")`
        }
        handle @ghost_slug_filter_block {
                respond 403
        }

and then restarted the ghost-caddy-1 container.

:police_car_light:

NOTE: Please be aware that everyoneā€™s environment is different, so while this appears to work for me, it may not for you. I offer no guarantees it works well for me, you, or anyone.

:police_car_light:

2 Likes
31

Fix is live:

Thanks for sharing your snippet @mbdmbd. I would have done the same thing with my Nginx reverse proxy, I just didnā€™t have time to fuss with it today, and didnā€™t want to deploy a fix that I hadnā€™t properly tested.

2 Likes
32

It seems to be partially live. The page is reporting both that there are 6.19.1* images available, but also on the right hand side that the latest image is four days old. When I do a docker compose pull it still seems to be getting the older image (6.18.2) for me:

IMAGE ID DISK USAGE CONTENT SIZE EXTRA
ghost:6-alpine 2ec674f6f4cb 1.25GB 213MB U

And when I try and pull the 6.19.1 directly it fails:

$ docker pull ghost:6.19.1-alpine
Error response from daemon: manifest for ghost:6.19.1-alpine not found: manifest unknown: manifest unknown

I have no doubt itā€™s coming soon, but it doesnā€™t appear to be here quite yetā€¦

1 Like
33

Looks like itā€™s live for me now too :tada:

34

I just got the fix! I still see the ā€œfour days oldā€ but docker pulled the new image.

35

Iā€™m really appreciative that the Docker image was just updated, thank you to the folks who pulled all this together!

I feel like if Docker is a ā€œcommunity-maintainedā€ installation method and not officially supported by Ghost, the docs should really reflect that. I read through the entire installation doc again tonight and I donā€™t see anywhere it says itā€™s ā€œcommunity-maintainedā€. In fact, it says ā€œwe are previewingā€ and ā€œweā€™re starting to build some features as separate servicesā€, which absolutely led me to believe that Ghost was supporting this method of installation. I feel strongly that the Docker image should be maintained by Ghost in a formal capacity, or the docs should be modified to reflect that Docker is a purely community-maintained installation method.

4 Likes
36

I agree with @veronicaexplains, if the official method is not really kept up to date with releases, it does make you wonder how supported self-hosting really is.

And for me, since v6 this is how it feels. You can self host (and thank you for that, really!) but it has not been the smoothest experience. Docker images being behind on security fixes is one thing, but I also find it hard sometimes to know what works differently when you self host. Like the ActivityPub and PubSub situation, I was not sure what that meant for us.

I think most of us would just like to know where we stand. Even if something is not fully supported, just knowing that would already help a lot.

3 Likes
37

Thereā€™s an official post in the forum about this now here:

It includes this statement:

Weā€™re actively working on improving when and how we release security updates to the Docker image.

Otherwise it does not contain new information.

2 Likes
38

Hi everyone

Thanks for raising this, and Iā€™m really sorry we dropped the ball here. There have been multiple failures on our part that have led to a situation that falls well short of our standards.

  • Recommending Docker usage without the Ghost core team maintaining the Docker image
  • Releasing a security update without providing an update path via the recommended Docker image
  • Releasing a security disclosure without there being sufficient time for anyone to update
  • Sending a confusingly formatted, unhelpful security update notification by email

I want to own and acknowledge that this is not good enough, and I want to share what weā€™re doing about it:

First - until now, our developer tooling and release process has been a shared responsibility between our engineering teams. That worked fine for a long time while Ghost was smaller, but it no longer works, today. The surface area is too large, and it needs to be someoneā€™s fulltime job.

As a result, weā€™re immediately hiring for (two) fulltime platform engineering positions. If you know anyone who might be a good fit, please send them our way.

Second - the Ghost Docker image will become the official first-class way to run Ghost, and it will be supported, maintained, and released by the Ghost core team. That will be one of the first projects we ask new platform engineers to work on.

Itā€™s not going to happen overnight, it will take some time, but we will get it done.

Until we complete that transition, we will coordinate any future security releases and make sure there is a Docker upgrade path immediately available - and that the disclosure of security issues is better communicated, with time to complete updates before publishing the details of the issue.

Weā€™ve made (and will continue to make) changes to our incident response and security release processes to do better, and make sure we donā€™t repeat the same mistakes in the way we have here.

The responsibility for this lies squarely with me. I havenā€™t done a good job of prioritizing this work and the resources needed to do it.

Iā€™m going to put that right.

18 Likes
39

Hi @John thanks for your feedback and all the work you and the team are doing. Iā€™m sure youā€™ll achieve the goals and even more.

Please consider our interest in collaborating and helping as a community. I would personally love to get involved as a volunteer contributor.

Regards!

5 Likes
40

As a new Ghost user, thanks for putting this out there. Looking forward to seeing how this shapes up. When the Docker installation is out of preview, I plan to cover it both on my blog and via video.

I appreciate all of the work team Ghost is doing, as well as the Docker maintainers and the community for helping each other navigate all of this!

8 Likes