Current 2.8.4 image contain critical security vulnerability

[shahar-davidson]

As of today, the latest Caddy 2.8.4 for Alpine contains a security vulnerability that is ranked as Critical: CVE-2024-24790⁠ (published on June 4, 2024)

This vulnerability appears to have been fixed already in the latest golang:1.22 for Alpine image.

Therefore, caddy image needs to be recreated with the latest Golang image (1.22.4 or later)

[dewbjorn]

Having the exact same issue

[francislavoie]

IMO that CVE is way overclassified. It's not that severe at all. It's just a minor bug. I'm pretty sure it's not a problem for any Caddy users, we don't check if an IP is loopback in security sensitive contexts. If someone can show a case where that can happen, then it would be more of a concern.

[shahar-davidson]

That's true - it's seems overclassified for Caddy.
But if a newer Caddy image can be created with a bumped Golang version then that would be nice.

[JinChin24]

That's true - it's seems overclassified for Caddy. But if a newer Caddy image can be created with a bumped Golang version then that would be nice.

Somebody know where is a good tutorial for build this ?

[jdvorak001]

Also dependabot is suggesting a new release: caddyserver/caddy#365 and caddyserver/caddy#366. See also #367.

[hackerfactor]

Any update on when this will be patched? Even if it doesn't really impact caddy, many companies focus on scanner outputs. If the scanner says "there's a critical CVE in that code", then it doesn't get deployed -- period.

[francislavoie]

We're waiting for 2.9.1 fixes

[mholt]

If the scanner says "there's a critical CVE in that code", then it doesn't get deployed -- period.

You know, in a sense, the CVE ecosystem is like a DoS against companies because they let it be.

[hackerfactor]

If the scanner says "there's a critical CVE in that code", then it doesn't get deployed -- period.

You know, in a sense, the CVE ecosystem is like a DoS against companies because they let it be.

I'm certainly not defending the CVE system. It has it's problems, and many companies misinterpret the purpose.
However, it is better than nothing, and in many cases, general heuristics like "no known critical CVEs in production" end up preventing more problems than they cause.

Moreover:

1. Not everyone has time to dive into the code and determine if the CVE applies to their situation. This is why companies set basic rules like "no criticals" and "must justify any 'high' and 'medium' vulnerabilities". There are a bunch of CVEs marked as 'high' or 'medium' with 'no fix available', 'missing details so no patch issued', or "does not apply to this platform" (e.g., bug is for MacOS version only, and this is the Linux version). These are easy to justify.
2. Even in cases where the CVE does not apply, I've never heard of a case where updating the code, so it no longer is flagged as having a CVE issue, ended up requiring a major rewrite to fix the problem. The vast majority of the time, simply updating a package solves the problem. (The most severe case I know of: migrating from OpenSSL 1.x to 3.x did require some code changes, but nothing earth shattering. Then again, this was a major version update, and the old version was past EOL so the update was required.) For Caddy, updating the 'go' version doesn't seem like a major rewrite issue.

[hackerfactor]

We're waiting for 2.9.1 fixes

2.9.1 just came out. The critical and high vulnerabilities have not been addressed.

$ ./caddy -v
v2.9.1 h1:OEYiZ7DbCzAWVb6TNEkjRcSCRGHVoZsJinoDR/n9oaY=
$ grype ./caddy
 ✔ Vulnerability DB                [updated]  
 ✔ Indexed file system
 ✔ Cataloged contents                                                              f5865824542ec9015fd8c7379b59645d1641690f915ce23047da05e20e18fbaf
   ├── ✔ Packages                        [126 packages]  
   └── ✔ Executables                     [1 executables]  
 ✔ Scanned for vulnerabilities     [0 vulnerability matches]  
   ├── by severity: 1 critical, 3 high, 2 medium, 0 low, 0 negligible
   └── by status:   6 fixed, 0 not-fixed, 0 ignored 
NAME    INSTALLED  FIXED-IN         TYPE       VULNERABILITY   SEVERITY 
stdlib  go1.22.3   1.21.11, 1.22.4  go-module  CVE-2024-24790  Critical  
stdlib  go1.22.3   1.22.7, 1.23.1   go-module  CVE-2024-34158  High      
stdlib  go1.22.3   1.22.7, 1.23.1   go-module  CVE-2024-34156  High      
stdlib  go1.22.3   1.21.12, 1.22.5  go-module  CVE-2024-24791  High      
stdlib  go1.22.3   1.22.7, 1.23.1   go-module  CVE-2024-34155  Medium    
stdlib  go1.22.3   1.21.11, 1.22.4  go-module  CVE-2024-24789  Medium

[francislavoie]

docker-library/official-images#18209 it'll be available soon (once the jenkins build queue finishes)

[jjlin]

@hackerfactor Did you make your own Caddy v2.9.1 build with an outdated (Go 1.22.3) toolchain?

For me, the (amd64) binary release at https://github.com/caddyserver/caddy/releases/tag/v2.9.1 gives:

$ sha256sum ./caddy
4346f0fbb320f9eefb19137e7c1239d9836f55c0bf7f36a1efc20191bc645cb5  ./caddy
$ go version -m ./caddy | fgrep go1.
./caddy: go1.23.4
$ ./caddy --version
v2.9.1 h1:OEYiZ7DbCzAWVb6TNEkjRcSCRGHVoZsJinoDR/n9oaY=
$ ./grype --version
grype 0.86.1
$ ./grype ./caddy
 ✔ Indexed file system                                                                                                                                                                                                                                                            ./caddy
 ✔ Cataloged contents                                                                                                                                                                                                    b68daf61516c33dc03d87db97491b4008be4aeb2d51443d3e861dddb4021a3db
   ├── ✔ Packages                        [116 packages]
   ├── ✔ File digests                    [1 files]
   ├── ✔ File metadata                   [1 locations]
   └── ✔ Executables                     [1 executables]
 ✔ Scanned for vulnerabilities     [0 vulnerability matches]
   ├── by severity: 0 critical, 0 high, 0 medium, 0 low, 0 negligible
   └── by status:   0 fixed, 0 not-fixed, 0 ignored
No vulnerabilities found

[hackerfactor]

@hackerfactor Did you make your own Caddy v2.9.1 build with an outdated (Go 1.22.3) toolchain?

I went to https://caddyserver.com/download and clicked the download button.

[jjlin]

@hackerfactor Did you make your own Caddy v2.9.1 build with an outdated (Go 1.22.3) toolchain?

I went to https://caddyserver.com/download and clicked the download button.

Ah, it looks like that does get built with 1.22.3, so it would seem https://caddyserver.com/download needs to do a better job at keeping its toolchain updated. The official Docker image will pull the GitHub release binary though, AFAIK.

[mholt]

I'll update the Go version when I'm back at my computer. 👍

[mholt]

Actually, upon investigating, the build server is using 1.23 already. And the build cache was reset, so when I download Caddy from the download page I get a build on 1.23.

[hackerfactor]

Just rechecked. Fixed. Thank you.