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

Disable HTTP/2 for webhook #7235

Closed
khrm opened this issue Oct 19, 2023 · 5 comments · Fixed by #7324
Closed

Disable HTTP/2 for webhook #7235

khrm opened this issue Oct 19, 2023 · 5 comments · Fixed by #7324
Assignees
Labels
kind/security Categorizes issue or PR as related to a security issue priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now.

Comments

@khrm
Copy link
Contributor

khrm commented Oct 19, 2023

We need to disable HTTP/2 for webhooks.

"
The go runtime does have a fix to mitigate the CVE-2023-44487 to a degree, but as kubernetes/kubernetes#121197 shows, a single connection attempting to perform a denial-of-service attack against a go-based HTTP/2 server resulted in the server process quickly consuming 5 GB of memory. Additional connections would likely result in an OOM situation very quickly.
"
Please check this: kubernetes/kubernetes#121197

/kind security

@tekton-robot tekton-robot added the kind/security Categorizes issue or PR as related to a security issue label Oct 19, 2023
@vdemeester vdemeester added the priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now. label Oct 23, 2023
@vdemeester
Copy link
Member

@tektoncd/core-maintainers what do we do around GHSA-qppj-fm5r-hxr3 ? As linked by @khrm in kubernetes/kubernetes#121197 most project seems to disable HTTP/2 server for webhooks (or "force HTTP 1.1" which is the same for now 😛 ) to make sure they are not exposed to this.

@dibyom
Copy link
Member

dibyom commented Oct 23, 2023

Disabling HTTP2 sounds fine though do we know to what extent do we think our webhooks are impacted? Our webhooks are internal only right i.e. its the API server that is sending requests vs an untrusted user. So, ensuring the API server has mitigated this attack is critical

@dibyom
Copy link
Member

dibyom commented Oct 31, 2023

@khrm @vdemeester is this still a critical/urgent?

@dibyom
Copy link
Member

dibyom commented Oct 31, 2023

From @khrm - this fix comes from knative, we should update our dependency when it is fixed

@khrm
Copy link
Contributor Author

khrm commented Nov 2, 2023

/assign @khrm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/security Categorizes issue or PR as related to a security issue priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants