Skip to content

Fix 4 Golang vulnerabilities in CodeFlare Operator #340

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

Closed
jbusche opened this issue Oct 16, 2023 · 2 comments · Fixed by #341
Closed

Fix 4 Golang vulnerabilities in CodeFlare Operator #340

jbusche opened this issue Oct 16, 2023 · 2 comments · Fixed by #341
Assignees

Comments

@jbusche
Copy link
Collaborator

jbusche commented Oct 16, 2023

Describe the Bug

Attempt to fix 4 Golang vulnerabilities in CodeFlare Operator

cvss    riskFactors     cve     link    hasFix  status  packageType     packageName     packageVersion  packageLicense  packageBinaryPkgs       packagePath
 description
5.4     Has fix,Medium severity PRISMA-2022-0270        https://github.com/golang-jwt/jwt/issues/223    Y       fixed in v4.4.3 go      github.com/golang-jwt/jwt/v4    v4.4.1                  /manager        github.com/golang-jwt/jwt/v4 module prior to v4.4.3 is vulnerable to Denial of Service (DoS). In case one of the RegisteredClaims params is empty it can lead to panic.
0       Attack complexity: low,Attack vector: network,DoS - High,Has fix,Medium severity,Recent vulnerability   CVE-2023-39325  https://nvd.nist.gov/vuln/detail/CVE-2023-39325 Y       fixed in 0.17.0 go      golang.org/x/net        v0.12.0                 /manager        A malicious HTTP/2 client which rapidly creates requests and immediately resets them can cause excessive server resource consumption. While the total number of requests is bounded by the http2.Server.MaxConcurrentStreams setting, resetting an in-progress request allows the attacker to create a new request while the existing one is still executing. With the fix applied, HTTP/2 servers now bound the number of simultaneously executing handler goroutines to the stream concurrency limit (MaxConcurrentStreams). New requests arriving when at the limit (which can only happen after the client has reset an existing, in-flight request) will be queued until a handler exits. If the request queue grows too large, the server will terminate the connection. This issue is also fixed in golang.org/x/net/http2 for users manually configuring HTTP/2. The default stream concurrency limit is 250 streams (requests) per HTTP/2 connection. This value may be adjusted using the golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams setting and the ConfigureServer function.
6.1     Attack complexity: low,Attack vector: network,Has fix,Medium severity,Recent vulnerability      CVE-2023-3978   https://nvd.nist.gov/vuln/detail/CVE-2023-3978  Y       fixed in 0.13.0 go      golang.org/x/net        v0.12.0                 /manager        Text nodes not in the HTML namespace are incorrectly literally rendered, causing text which should be escaped to not be. This could lead to an XSS attack.
5.3     Attack complexity: low,Attack vector: network,DoS - High,Exploit exists - in the wild,Has fix,Medium severity,Recent vulnerability      CVE-2023-44487  https://nvd.nist.gov/vuln/detail/CVE-2023-44487 Y       fixed in 0.17.0 go      golang.org/x/net        v0.12.0                 /manager        The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.

Codeflare Stack Component Versions

Latest build from main
Please specify the component versions in which you have encountered this bug.

Codeflare SDK: n/a
MCAD: built in
Instascale: built in
Codeflare Operator: main branch
Other:

Steps to Reproduce the Bug

  1. Build the image from main, scan it with Twistlock and view the Golang vulnerabilities.

What Have You Already Tried to Debug the Issue?

Trying out fixes in a branch here
https://github.com/jbusche/codeflare-operator/tree/jbusche-gomod-cfo

Expected Behavior

After updating the go.mod and go.sum, I expect the vulnerabilities to go from:

C:1|H:1|M:8|L:0|T:10
to
C:1|H:1|M:4|L:0|T:6

Screenshots, Console Output, Logs, etc.

Add screenshots of UIs (like dashboards), etc. that help explain the issue.

Affected Releases

List any release versions, git commit hashes, or git tags, etc. that you know show the bug. If it is the latest HEAD on main, just put that.

Additional Context

Add as applicable and when known:

  • OS: 1) MacOS, 2) Linux, 3) Windows: [1 - 3]
  • OS Version: [e.g. RedHat Linux X.Y.Z, MacOS Monterey, ...]
  • Browser (UI issues): 1) Chrome, 2) Safari, 3) Firefox, 4) Other (describe): [1 - 4 + description?]
  • Browser Version (UI issues): [e.g. Firefix 97.0]
  • Cloud: 1) AWS, 2) IBM Cloud, 3) Other (describe), or 4) on-premise: [1 - 4 + description?]
  • Kubernetes: 1) OpenShift, 2) Other K8s [1 - 2 + description]
  • OpenShift or K8s version: [e.g. 1.23.1]
  • Other relevant info

Add any other information you think might be useful here.

@jbusche
Copy link
Collaborator Author

jbusche commented Oct 18, 2023

Created PR #341
Testing it now...

@jbusche
Copy link
Collaborator Author

jbusche commented Oct 19, 2023

It's looking good! I've run the tests and it's looking good.
The Twistlock has now not showing any vulnerabilities for anything other than the go 1.19 issues

C:1|H:0|M:2|L:0|T:3

and mcad testing looked good:

All 20 appwrappers finished: 16:17:23
Total amount of time for 20 appwrappers is: 132 seconds

And I did the guided notebooks and they looked good

Job finished successfully.

@jbusche jbusche moved this from In Progress to Ready For Review in Project CodeFlare Sprint Board Oct 19, 2023
@github-project-automation github-project-automation bot moved this from Ready For Review to Done in Project CodeFlare Sprint Board Oct 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging a pull request may close this issue.

1 participant