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

Possible DoS by using overlapping multiple SinkBindings #5749

Open
cardil opened this issue Sep 21, 2021 · 6 comments
Open

Possible DoS by using overlapping multiple SinkBindings #5749

cardil opened this issue Sep 21, 2021 · 6 comments
Labels
area/security kind/bug Categorizes issue or PR as related to a bug. triage/accepted Issues which should be fixed (post-triage)

Comments

@cardil
Copy link
Contributor

cardil commented Sep 21, 2021

Describe the bug
Eventing allows users to create a faulty situation, where multiple sink bindings are constantly reconfiguring a single subject. This may lead to a DoS of a whole Kubernetes cluster, by resource depletion. Such situation can happen both intentionally, but also by chance by using different but overlapping labels.

$ kn source binding list
NAME     SUBJECT                                    SINK                 AGE   CONDITIONS   READY   REASON
bind-1   Service:serving.knative.dev/v1:takeme      ksvc:event-display   39s   2 OK / 2     True    
bind-2   Service:serving.knative.dev/v1:foo=bar     ksvc:event-display   31s   2 OK / 2     True    
bind-3   Service:serving.knative.dev/v1:fizz=bazz   ksvc:event-display   11s   2 OK / 2     True    
bind-4   Service:serving.knative.dev/v1:moo=goo     ksvc:event-display   4s    2 OK / 2     True 

$ kubectl get kservice takeme -o jsonpath='{.metadata.generation}'
9803

Expected behavior
Knative Eventing should detect that multiple SinkBindings are targeting overlapping resources, and mark them as not ready, showing misconfiguration to user in status. This validation should happen no matter if SB are selecting subject by name or by label selector.

To Reproduce

  1. Create sink ex.: kn service create event-display --image gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display
  2. Create a subject that sink bindings will fight for, ex.: kn service create takeme --image=gcr.io/knative-samples/helloworld-go -l foo=bar -l fizz=bazz -l moo=goo
  3. Create more than one sink binding that targets the same subject:
    1. kn source binding create bind-1 --subject 'Service:serving.knative.dev/v1:takeme' --sink event-display --ce-override 'sink=1'
    2. kn source binding create bind-2 --subject 'Service:serving.knative.dev/v1:foo=bar' --sink event-display --ce-override 'sink=2'
    3. kn source binding create bind-3 --subject 'Service:serving.knative.dev/v1:fizz=bazz' --sink event-display --ce-override 'sink=3'
    4. kn source binding create bind-4 --subject 'Service:serving.knative.dev/v1:moo=goo' --sink event-display --ce-override 'sink=4'

Knative release version
main

Additional context

Resolving this issue would probably fix #5510 as well.

@cardil cardil added the kind/bug Categorizes issue or PR as related to a bug. label Sep 21, 2021
@cardil
Copy link
Contributor Author

cardil commented Sep 21, 2021

/area security

@cardil
Copy link
Contributor Author

cardil commented Sep 23, 2021

Maybe this issue should be treated as CWE-400

@cardil
Copy link
Contributor Author

cardil commented Oct 5, 2021

@knative/security-wg-leads PTAL

@github-actions
Copy link

github-actions bot commented Jan 4, 2022

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 4, 2022
@rhuss
Copy link
Contributor

rhuss commented Jan 4, 2022

/remove-lifecycle stale

@knative-prow-robot knative-prow-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 4, 2022
@pierDipi
Copy link
Member

pierDipi commented Jan 4, 2022

/triage accepted

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/security kind/bug Categorizes issue or PR as related to a bug. triage/accepted Issues which should be fixed (post-triage)
Projects
None yet
Development

No branches or pull requests

4 participants