This image is reported as affected by CVE-2024-24790

[pranjalthakur98]

We are using Rabbitmq as a base image to develop application on the top of it but we are tagged with a critical vulnerability of Go (golang) [CVE-2024-24790⁠]. This is stopping us from using it.
Can this vulnerability could be fixed ?
We could see this is only with 4.* version of rabbitmq image with ubuntu OS.

[michaelklishin]

@pranjalthakur98 this image does not ship any Go binaries. Therefore it cannot be affected by CVE-2024-24790: no Go-based servers are started as part of this image.

[michaelklishin]

@pranjalthakur98 RabbitMQ is not a Go-based tool, so I do not see how your claim can be true. The title is therefore making a bold claim without providing any evidence of a vulnerability in RabbitMQ.

CVE-2024-24790 details in the NIST database further confirm that the issue is in the Go IP/socket implementation, so any Go tooling involved at build time would not affect this image or RabbitMQ.

Please post some evidence or this won't be taken seriously.

[michaelklishin]

@tianon @yosifkit while we don't have any details or proof here to work with, as a general question,
what is the official image policy w.r.t. Go vulnerabilities? Go is so heavily used throughput the OCI tooling space that I can see how a net/netip or archive/zip vulnerability can be "attributed" to an image by automatic scanners, even though no started processes are actually Go-based.

This is not the first "issue report" to stem from an automated scan and it won't be the last, so I'd like to understand how official images in general approach this problem.

[tianon]

I'm guessing this is related to the gosu binary, and it's most certainly not "vulnerable" to CVE-2024-24790: https://github.com/tianon/gosu/blob/HEAD/SECURITY.md (the code for gosu doesn't invoke any of net/http, archive/zip, etc)

rabbitmq/4.0/ubuntu/Dockerfile

Line 254 in 4d38471

gosu \

FWIW, I have run govulncheck on the gosu binary from the rabbitmq image, and it gets really confused and lists a bunch of things that can't possibly be accurate, and I'm not actually sure why it does. The only thing different about it is that it comes from Ubuntu's package and is built against a newer version of Go than the ones I publish, which should be better in this respect, not worse.

We also usually link to https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-cves to help explain why security scanners might say one thing or another, and why it's almost never the full story.

[tianon]

Oh, I bet the Ubuntu builds strip the binary, so govulncheck can't know the symbols for sure: https://github.com/tianon/gosu/blob/4233b796eeb3ba76c8597a46d89eab1f116188e2/Dockerfile#L11

[michaelklishin]

CVE scanners that produce false positives is something very common to see. Thank you for taking a closer look. https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-cves looks very relevant indeed.

[tianon]

It'll take a long time before it trickles down to an Ubuntu release, but I'm planning to apply https://salsa.debian.org/go-team/packages/gosu/-/commit/84e4d54dff129d01a71efd6d2823a7ffdfcef9dc in Debian to explicitly combat this problem (of govulncheck not being able to scan the binary properly/accurately).

[michaelklishin]

Sounds great, thank you so much!