Status of security vulnerabilities?

[mdbraber]

In September 2023 several security vulnerabilities were reported - almost all of them are still open at this time:

266 IP Spoofing via X-Forwarded-For Header (severity: medium)

267 Referer-Based Header XSS (severity: medium)

268 Open Redirection Vulnerability (severyity: medium)

269 X-Forwarded-Host Header Manipulation (severity: medium)

270 X-Forwarded-Proto Header Manipulation (severity: low)

271 2FA Bypass by Brute-Forcing Verification Codes (severity: low)

272 Lack of User Session Invalidation on Logout (severity: low)

273 Stored XSS in admin panel triggerable by CSRF (severity: high)

274 No CSRF Mitigation in Caddy Security Admin Panel

275 ReadFileBytes panics when a provided path is empty

https://github.com/search?q=repo%3Agreenpau%2Fcaddy-security%20is%3Aissue%20is%3Aopen%20label%3Asecurity%20&type=issues

@ahpaleus reported these and wrote a report here https://blog.trailofbits.com/2023/09/18/security-flaws-in-an-sso-plugin-for-caddy/. The report mentions that @greenpau indicated there were no near-term plans to act on these vulnerabilities.

I thoroughly appreciate all the work a maintainer like @greenpau is doing as a FOSS maintainer on building caddy-security. At the same time I'm wondering what is the likeliness caddy-security could be considered safe enough to use in a (semi)production environment to secure sensitive information. @greenpau do you have any ideas / suggestions on how to assess these issues?

Thanks for considering!

[gedw99]

Thanks for raising this..

Spoke too soon. I see the Severity against each one. thanks for adding that !!

[greenpau]

@mdbraber , majority of these vulnerabilities are not directly related to the plugin. They are something that you would harden yourself. For example, you can configure caddy to drop/block X headers.

ReadFileBytes panics when a provided path is empty

if one considers the above a security vulnerability … lol

[greenpau]

Stored XSS in admin panel triggerable by CSRF

@mdbraber , the admin panel was completely rebuild. That issue is not being valid.

[greenpau]

@mdbraber , more importantly … do you see the people who reported these vulnerabilities being engaged? It is like 10 person team. Ask yourself the reason they reported it. Are they working for someone looking to undermine caddy server? These are hired guns.

From their website. Apparently, I need to hire them to fix the bugs they found.

[greenpau]

@mdbraber , take a look at these.

https://github.com/greenpau/caddy-security/issues/266 IP Spoofing via X-Forwarded-For Header (severity: medium) https://github.com/greenpau/caddy-security/issues/269 X-Forwarded-Host Header Manipulation (severity: medium) https://github.com/greenpau/caddy-security/issues/270 X-Forwarded-Proto Header Manipulation (severity: low)

Say you can spoof X- header (I spoof User Agent header), what would that give you? What is the impact? Why spoofing X-Forwarded-Host is medium and X-Forwarded-Proto is low?

[greenpau]

@mdbraber , thank you for raising this issue. It helps refreshing memory around the issue. I try my best to patch what I see is valid. For example, please see my comment here: https://github.com/greenpau/caddy-security/issues/268#issuecomment-2217678480.

[dguido]

Hey @greenpau, as we mentioned in the blog post, we reviewed your software because we were considering using it. We're not working for anyone else, and we weren't asked to review it by anyone else. Also, we are a 125 person team.

We reported these vulnerabilities to you privately first, but you responded that you wouldn't be fixing them. As is standard for the security community, we then put out an advisory to help users of this software be aware and mitigate these security issues through other means.

The writeup on our blog clearly articulates a patching strategy for each bug, including both short and long-term fixes. I would encourage you to help setup efforts to solicit patches and remediation efforts along those lines.

-Dan (the CEO)

[greenpau]

Also, we are a 125 person team.

@dguido , that’s what I mean. You have a large team of individuals. If you wanted to fix something, commit resources and fix it. Filing nonsense like “ ReadFileBytes panics when a provided path is empty” does not help anyone.

We reported these vulnerabilities to you privately first, but you responded that you wouldn't be fixing them. As is standard for the security community, we then put out an advisory to help users of this software be aware and mitigate these security issues through other means.

Whoever reads it, ask yourselves what would you do when a “corporation” comes to you and asks you to fix something? And how would you respond? That “ask” comes with a threat of publishing by X date if you are not fixing it. Well … I said nicely “* you. Not doing it.”

The writeup on our blog clearly articulates a patching strategy for each bug, including both short and long-term fixes. I would encourage you to help setup efforts to solicit patches and remediation efforts along those lines.

OK.

[greenpau]

@dguido , I thank you and your team for doing the assessment. I did address some of the issues you team uncovered (redirect url), but did it on my own timeline and when I had the time. I do take issue with the quality of some of the findings.

[mdbraber]

@greenpau @dguido thanks for chiming in; I'm thankful to see these issues (whether or not specifically security related) are getting some attention. I'll close this issue as we can track the other individual issues.