Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

config-reloader:v0.0.5 is built with old vulnerable version of go #1806

Closed
kefiras opened this issue Sep 3, 2024 · 2 comments
Closed

config-reloader:v0.0.5 is built with old vulnerable version of go #1806

kefiras opened this issue Sep 3, 2024 · 2 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@kefiras
Copy link

kefiras commented Sep 3, 2024

Bugs should be filed for issues encountered whilst operating logging-operator.
You should first attempt to resolve your issues through the community support
channels, e.g. Slack, in order to rule out individual configuration errors. #logging-operator
Please provide as much detail as possible.

Describe the bug:
The image is reported as vulnerable due to old go version used to build id

Expected behaviour:
The image should be build using newer version of GO, for example 1.20.8

Steps to reproduce the bug:
N/A

Additional context:
List of vulnerabilities:
'''
Vulnerability: The go command may execute arbitrary code at build time when using cgo. This may occur when running "go get" on a malicious module, or when running any other command which builds untrusted code. This is can by triggered by linker flags, specified via a "#cgo LDFLAGS" directive. Flags containing embedded spaces are mishandled, allowing disallowed flags to be smuggled through the LDFLAGS sanitization by including them in the argument of another flag. This only affects usage of the gccgo compiler., SOLUTION:["1.19.10","1.20.5"]

Vulnerability: The go command may execute arbitrary code at build time when using cgo. This may occur when running "go get" on a malicious module, or when running any other command which builds untrusted code. This is can by triggered by linker flags, specified via a "#cgo LDFLAGS" directive. The arguments for a number of flags which are non-optional are incorrectly considered optional, allowing disallowed flags to be smuggled through the LDFLAGS sanitization. This affects usage of both the gc and gccgo compilers., SOLUTION:["1.19.10","1.20.5"]

Vulnerability: On Unix platforms, the Go runtime does not behave differently when a binary is run with the setuid/setgid bits. This can be dangerous in certain cases, such as when dumping memory state, or assuming the status of standard i/o file descriptors. If a setuid/setgid binary is executed with standard I/O file descriptors closed, opening any files can result in unexpected content being read or written with elevated privileges. Similarly, if a setuid/setgid program is terminated, either via panic or signal, it may leak the contents of its registers., SOLUTION:["1.19.10","1.20.5"]

Vulnerability: The go command may generate unexpected code at build time when using cgo. This may result in unexpected behavior when running a go program which uses cgo. This may occur when running an untrusted module which contains directories with newline characters in their names. Modules which are retrieved using the go command, i.e. via "go get", are not affected (modules retrieved using GOPATH-mode, i.e. GO111MODULE=off, may be affected)., SOLUTION:["1.19.10","1.20.5"]

Vulnerability: The HTTP/1 client does not fully validate the contents of the Host header. A maliciously crafted Host header can inject additional headers or entire requests. With fix, the HTTP/1 client now refuses to send requests containing an invalid Request.Host or Request.URL.Host value., SOLUTION:["1.19.11","1.20.6"]

Vulnerability: Extremely large RSA keys in certificate chains can cause a client/server to expend significant CPU time verifying signatures. With fix, the size of RSA keys transmitted during handshakes is restricted to <= 8192 bits. Based on a survey of publicly trusted RSA keys, there are currently only three certificates in circulation with keys larger than this, and all three appear to be test certificates that are not actively deployed. It is possible there are larger keys in use in private PKIs, but we target the web PKI, so causing breakage here in the interests of increasing the default safety of users of crypto/tls seems reasonable., SOLUTION:["1.19.12","1.20.7","1.21.0-rc.4"]

Vulnerability: The html/template package does not apply the proper rules for handling occurrences of "<script", "<!--", and "</script" within JS literals in <script> contexts. This may cause the template parser to improperly consider script contexts to be terminated early, causing actions to be improperly escaped. This could be leveraged to perform an XSS attack., SOLUTION:["1.20.8","1.21.1"]

Vulnerability: The html/template package does not properly handle HTML-like "" comment tokens, nor hashbang "#!" comment tokens, in <script> contexts. This may cause the template parser to improperly interpret the contents of <script> contexts, causing actions to be improperly escaped. This may be leveraged to perform an XSS attack., SOLUTION:["1.20.8","1.21.1"]

Environment details:

  • Kubernetes version (e.g. v1.15.2): 1.28.9
  • Cloud-provider/provisioner (e.g. AKS, GKE, EKS, PKE etc): AKS
  • logging-operator version (e.g. 2.1.1): 4.6.0
  • Install method (e.g. helm or static manifests): helm
  • Logs from the misbehaving component (and any other relevant logs):
  • Resource definition (possibly in YAML format) that caused the issue, without sensitive data:

/kind bug

@kefiras kefiras added the bug Something isn't working label Sep 3, 2024
@pepov pepov added this to the 4.10 milestone Sep 9, 2024
@pepov
Copy link
Member

pepov commented Sep 9, 2024

@pepov pepov self-assigned this Sep 24, 2024
@pepov
Copy link
Member

pepov commented Sep 27, 2024

Updated in #1814 will be part of 4.10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Archived in project
Development

No branches or pull requests

2 participants