search

tianon / gosu

Simple Go-based setuid+setgid+setgroups+exec
Apache License 2.0
4.68k stars 312 forks source link

CVEs that do not apply to gosu #104

Closed tianon closed 1 year ago

tianon commented 2 years ago

NOTE: this list is no longer actively maintained; see https://github.com/tianon/gosu/issues/104#issuecomment-1358424738:

With https://github.com/tianon/gosu/releases/tag/1.15, I've now got https://github.com/tianon/gosu/blob/master/SECURITY.md which makes it clear how to determine whether vulnerabilities apply to a released version/build of gosu (TLDR, the answer is now govulncheck, which checks for invocations of the actual vulnerable functionality).

CVEs that do not apply to builds of gosu:

If you use (or maintain) a security scanner which reports any of these against gosu, please report them to the security vendor as false positives.

(See also https://snarky.ca/the-social-contract-of-open-source/)

HeyImAllan commented 2 years ago

Dear @tianon,

I would like to respectfully ask if there are any plans on life cycling the golang packages in the near future?

Thank you.

tianon commented 2 years ago

I try to keep the main development branch up-to-date with newer package versions, but I have no plans to make a new release of gosu unless there is a compelling reason to do so (changes to/CVEs in the actual codepaths gosu invokes, changes to gosu itself, etc).

yuriy-yarosh commented 2 years ago

@tianon please make a minor 1.15 release to update the runc to 1.1.2 and make people happy. golang.org/x/sys should be also updated to 0.0.0-20220412211240-33da011f77ad, according to trivy.

CVE wise I'm getting only two that actually bother me a bit CVE-2022-29162 / CVE-2022-29526

tianon commented 2 years ago
slakwa commented 2 years ago

@tianon can you take a look at CVE-2022-30635? Our scanner started to show it lately.

tianon commented 2 years ago
ZimboQC commented 1 year ago

Hi @tianon , Prisma found two new vulnerabilities :

Can you take a look? Thanks!

tianon commented 1 year ago

similar to many of the CVEs that are listed, "does not use math/big" / "does not use net/http"

liam-verta commented 1 year ago

I try to keep the main development branch up-to-date with newer package versions, but I have no plans to make a new release of gosu unless there is a compelling reason to do so (changes to/CVEs in the actual codepaths gosu invokes, changes to gosu itself, etc).

Let me get this straight. You'd rather maintain this growing list of false-positive CVEs and respond to continuing bug reports and requests rather than releasing a new incremental version that would clear most if not all of these reports?

Consumers of tools like this generally don't build it from source. They consume released artifacts. The last release doesn't include changes you've merged into master in the last 15 months. Those changes include dependency updates and even a new Go version. You've merged the changes why not release them?

I see your argument elsewhere that until there are "functional changes" you won't release a new version. I can see that reasoning. Following that reasoning the update to Go 1.19 should justify a new release. There have been a number of changes to Go compiler and runtime since gosu 1.14 was built and released. While the gosu code hasn't changed the build outputs and runtime behavior have. Based on your own comments that should be sufficient reason for a new release.

parth30 commented 1 year ago

Hi @tianon , Prisma found 3 new ones :

Can you please take a look if these are false positives as well ? Thanks

yosifkit commented 1 year ago
  • CVE-2022-2879 : Reader.Read does not set a limit on the maximum size of file headers. A maliciously crafted archive could cause Read to allocate unbounded amounts of memory, potentially causing resource exhaustion or panics. After fix, Reader.Read limits the maximum size of header blocks to 1 MiB.
  • CVE-2022-41715: Programs which compile regular expressions from untrusted sources may be vulnerable to memory exhaustion or denial of service. The parsed regexp representation is linear in the size of the input, but in some cases the constant factor can be as high as 40,000, making relatively small regexps consume much larger amounts of memory. After fix, each regexp being parsed is limited to a 256 MB memory footprint. Regular expressions whose representation would use more space than that are rejected. Normal use of regular expressions is unaffected.
  • CVE-2022-2880 : Requests forwarded by ReverseProxy include the raw query parameters from the inbound request, including unparseable parameters rejected by net/http. This could permit query parameter smuggling when a Go proxy forwards a parameter with an unparseable value. After fix, ReverseProxy sanitizes the query parameters in the forwarded query when the outbound request's Form field is set after the ReverseProxy. Director function returns, indicating that the proxy has parsed the query parameters. Proxies which do not parse query parameters continue to forward the original query parameters unchanged.

Can you please take a look if these are false positives as well ? Thanks

  1. gosu doesn't open archives
  2. gosu doesn't "compile regular expressions from untrusted sources"
  3. gosu doesn't make or receive any http(s) requests
tianon commented 1 year ago

With https://github.com/tianon/gosu/releases/tag/1.15, I've now got https://github.com/tianon/gosu/blob/master/SECURITY.md which makes it clear how to determine whether vulnerabilities apply to a released version/build of gosu (TLDR, the answer is now govulncheck, which checks for invocations of the actual vulnerable functionality).

ThomasKroghMortensen commented 1 year ago

@tianon Based on above mentioned https://github.com/tianon/gosu/blob/master/SECURITY.md, I see that two out of three new CVEs are not affecting [CVE-2022-32148, CVE-2022-41717], but the last one [CVE-2022-41716] is not covered, since it relates to Go os/exec?

CVE-2022-32148 is a net/http, so this is according to readme not affecting. CVE-2022-41717 is a net/http, so this is according to readme not affecting.

CVE-2022-41716 is a os/exec - So does it mean it is affecting?

tianon commented 1 year ago

Please run govulncheck on the binary to verify.

ThomasKroghMortensen commented 1 year ago

Thanks.

FYI:

# /gosu --version1.16 (go1.18.2 on linux/amd64; gc)
# govulncheck /gosu
govulncheck is an experimental tool. 
Share feedback at https://go.dev/s/govulncheck-feedback.
Scanning for dependencies with known vulnerabilities...
No vulnerabilities found.

# /gosu14 --version1.14 (go1.16.7 on linux/amd64; gc)
# govulncheck /gosu14
govulncheck is an experimental tool. 
Share feedback at https://go.dev/s/govulncheck-feedback.
Scanning for dependencies with known vulnerabilities...
govulncheck: vulncheck.Binary: binary built using unsupported Go Version: go1.16.7 

All fine - we will use redis 7.0.8 with gosu 1.16. (1.14 where where we had the CVEs), but we will upgrade to be sure.

ganshnec1030 commented 1 year ago

HI Team,

Thank you for all information available in this issue.

Prisma is showing CVE-2022-32190 for the gosu. Can you please take a look and let us know it's false positive or not?

Thanks.

tianon commented 1 year ago

Please run govulncheck on the binary to verify.

ganshnec1030 commented 1 year ago

Hello @tianon

Thank for your response and guidance.

We are getting issue while building govulncheck. Could you please check at your side if it's handy and let us know CVE-2022-32190 is false positive or not,

tianon commented 1 year ago 
$ ./gosu-amd64 --version
1.16 (go1.18.2 on linux/amd64; gc)

$ go install golang.org/x/vuln/cmd/govulncheck@latest
go: downloading golang.org/x/vuln v0.0.0-20230331150530-a42f9910daf3
go: downloading golang.org/x/mod v0.9.0
go: downloading golang.org/x/tools v0.7.0
go: downloading golang.org/x/sys v0.6.0

$ govulncheck ./gosu-amd64
govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback.

Using govulncheck@v0.0.0 with
vulnerability data from https://vuln.go.dev (last modified 2023-03-29 14:45:38 +0000 UTC).

Scanning your binary for known vulnerabilities...
No vulnerabilities found.
ganshnec1030 commented 1 year ago

HI @tianon

Thank you for your time and response.

Just want to double-check, govulncheck is not showing CVE-2022-32190 CVE, so can we mark it as false positive?

tianon commented 1 year ago

Please read https://github.com/tianon/gosu/blob/6a1967c98c3d1854dd29f32433f1e0c59b244c5f/SECURITY.md again, especially the third paragraph.

thekaibosh commented 1 year ago

@tianon would you add CVE-2023-28642 to this list please? I appreciate your position on CVEs related to go. I've got my SecOps team onboard with using this issue as justification for dismissing/reporting false postives

tianon commented 1 year ago

Unfortunately, no, I will not be updating/maintaining this list. I made a lot of changes to the way I build/release in support of the updated security policy (https://github.com/tianon/gosu/blob/master/SECURITY.md), in which I now treat the results of govulncheck as canonical because that tool is going to do a much more thorough check of whether the functions gosu actually invokes are affected by a given vulnerability than I could possibly do myself (and in addition, I now run govulncheck on gosu at least weekly via a scheduled GitHub Actions CI job, which is also public in this repository).

daniel-brenot commented 10 months ago

Can I just ask if there is something about updating to a new version of golang that poses more effort than updating all of these vulnerability tools? I understand that this project doesn't use the parts of the code that have the CVE at the moment, but I can't help but wonder if it is less effort to just update the go version than it is to ask all of the tools to ignore the warnings for this tool.

yuriy-yarosh commented 10 months ago

@daniel-brenot don't bother, just a matter of hubris and forced depreciation... I'm paranoid enough to conclude that it's actually a good thing - forces people to oversee their containers and maintain them well. Yet again, for some folks it actually became a business model, so it surely could be an opportunity.

CRCinAU commented 1 week ago

Can I just ask if there is something about updating to a new version of golang that poses more effort than updating all of these vulnerability tools? I understand that this project doesn't use the parts of the code that have the CVE at the moment, but I can't help but wonder if it is less effort to just update the go version than it is to ask all of the tools to ignore the warnings for this tool.

This would be nice. The thousands of people marking (currently) 52 "fixable" vulnerabilities as "yeah, its ok in this specific image" and potentially breaking things by "oh yeah, don't need to care about that" on packages that it actually does matter.

It's like training users to "Just click OK" or "Just allow it to elevate privs"...

However, if the author doesn't want to do that on behalf of their userbase, we can't force them.

tianon commented 1 week ago

If we, as the userbase of these "security scanning" tools, continue to accept the frankly poor status quo in the face of information/tooling that can trivially improve their false positive rates (govulncheck), nothing will improve. I'm not asking anyone to mark them as ignored (nor suggesting that anyone should do so) -- I'm asking you to actively report them to your scanner vendor as false positives and suggesting (demanding?) that they incorporate govulncheck into their tooling so that the situation can actually improve in a way that helps everyone using and writing Go-based tooling.

daniel-brenot commented 1 week ago

I understand your stance on this and appreciate it, but the end result here is that in the meantime everyone relying on this tool is having to constantly make security exceptions at their workplace. I do agree that the companies should fix their scanning(looking at you jfrog!), but this stance is involving everyone else here in the software politics, whether they like it or not.

At the end of the day this library is maintained by you and no one can force your hand, and you don't owe it to any of us. However you are passing software politics off to users who are dealing with this transitively and can't really opt out. In my case it's through a docker image that uses this and I don't have a good alternative to this library, so I'm stuck marking this as an exception.

As a thought of another way to approach this, updating the go libraries and making a new release is quite trivial to do and would make this vulnerability error go away for a large number of people for quite a while. If you want vulnerability scanning companies to make the exception and feel so strongly about it, I'd suggest that you yourself reach out to them with this suggestion. I promise you that jfrog does not care how many users complain about this issue, since at the end of the day they are just the most convenient solution for many people and have no reason to invest this effort into adding security scanning.

CRCinAU commented 1 week ago

I too totally understand your point. There is absolutely nothing wrong with it on a completely technical level. However we don't live in a completely technical world.

What it does do is to shift the burden onto the end users - of which, a percentage will end up here - and you'll waste even more time and brainpower in explaining all this to a newer set of users - again, and again, and again, and again. That's a lot of effort just to maintain the moral high-ground.

That same shift of burden ripples down to thousands of tech folks and thousands of projects. They too have to field these questions - because, say, Postgres will show (at least) 52 security vulnerabilities because of your stance on things. I'm sure the postgres guys in this scenario would prefer they didn't have to do this all the time as well.

The true cost and impact would be in the thousands of man hours - collectively, years of human effort to maintain this status quo. Myself? I'd rather be doing other things than trying to figure out which CVE relates to what component, if it matters for every one of the thousands of libraries that are present in modern day systems and be happier in life going "Yep, we're looking good" instead of writing exceptions, explaining to management why it never says "No security vulnerabilities" - and essentially training other staff by these actions that security vulnerability lists are there to be ignored - the subtlety there is dangerous long term.

Now, I don't have any skin in the game anymore - it was less effort for me personally to rip out gosu from my container and install a smaller, OS provided package that achieved the same end result as I needed - however mine was a VERY simple use case.

What I did do, was see what I saw to be a very strange stance that puzzled me as to why this was the case - and I've been grinding out code and systems for about 25 years now.

All that being said, I think you're dead wrong to defend sticking to an EOL version of GO and really hope that you at least keep things within supported versions - as security reports very rarely end up being published / accepted on EOL software - so you could no longer guarantee that any other tools you use would be updated to reflect reality once that magic EOL date passes.

I don't really expect any further replies - but would like @tianon to mull on these thoughts - as it does present somewhat of a mindset / culture shift on things. Just let it sit with you and peculate - like a good coffee :)