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

update prometheus client golang. fixes CVE-2022-21698 #134

Merged
merged 1 commit into from May 6, 2022

Conversation

hilariocoelho
Copy link
Contributor

Current prometheus client golang lib being used by of-watchod contains a vulnerability that has been fixed on v1.11.1 here

Description

As you can see, the generated docker container of of-watchdog contains the vulnerability and is reported using grype:

% syft ghcr.io/openfaas/of-watchdog:0.9.4 --output json | grype                                   
 ✔ Loaded image            
 ✔ Parsed image            
 ✔ Cataloged packages      [12 packages]

NAME                                 INSTALLED     FIXED-IN  TYPE       VULNERABILITY   SEVERITY 
github.com/prometheus/client_golang  v1.11.0                 go-module  CVE-2022-21698  High      
google.golang.org/protobuf           v1.26.0-rc.1            go-module  CVE-2015-5237   High      
google.golang.org/protobuf           v1.26.0-rc.1            go-module  CVE-2021-22570  High      

After updating the affected library and running make dist and make build, this is the generated report from grype:

% syft ghcr.io/openfaas/of-watchdog:latest --output json | grype
 ✔ Loaded image            
 ✔ Parsed image            
 ✔ Cataloged packages      [12 packages]

NAME                        INSTALLED     FIXED-IN  TYPE       VULNERABILITY   SEVERITY 
google.golang.org/protobuf  v1.26.0-rc.1            go-module  CVE-2015-5237   High      
google.golang.org/protobuf  v1.26.0-rc.1            go-module  CVE-2021-22570  High      

Motivation and Context

Fix a security vulnerability.

How Has This Been Tested?

Using grype

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I've read the CONTRIBUTION guide
  • I have signed-off my commits with git commit -s
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@derek derek bot added the new-contributor label May 5, 2022
@derek
Copy link

derek bot commented May 5, 2022

Thank you for your contribution. unfortunately, one or more of your commits are missing the required "Signed-off-by:" statement. Signing off is part of the Developer Certificate of Origin (DCO) which is used by this project.

Read the DCO and project contributing guide carefully, and amend your commits using the git CLI. Note that this does not require any cryptography, keys or special steps to be taken.

💡 Shall we fix this?

This will only take a few moments.

First, clone your fork and checkout this branch using the git CLI.

Next, set up your real name and email address:

git config --global user.name "Your Full Name"
git config --global user.email "you@domain.com"

Finally, run one of these commands to add the "Signed-off-by" line to your commits.

If you only have one commit so far then run: git commit --amend --signoff and then git push --force.
If you have multiple commits, watch this video.

Check that the message has been added properly by running "git log".

@derek derek bot added the no-dco label May 5, 2022
Signed-off-by: Hilário Coelho <hilario.coelho@securityside.com>
@alexellis
Copy link
Member

Hi @spawn2kill thanks for letting us know about the CVE in Prometheus.

For any concerned users, we must ask: "What is the likelihood of this being a risk for your environment?"

In client_golang prior to version 1.11.1, HTTP server is susceptible to a Denial of Service through unbounded cardinality, and potential memory exhaustion, when handling requests with non-standard HTTP methods.

It sounds like this only affects users who directly expose the expose the Prometheus HTTP server on the Internet? By default we run the Prometheus server on a separate private port, which is only available in-cluster. The risk should be extremely low for most users. If you see it differently, let me know.

There are other usages of the Prometheus HTTP handler such as the gateway, which would also benefit from a patch: https://github.com/openfaas/faas/tree/master/gateway

Along with the classic watchdog, which is very similar code for metrics: https://github.com/openfaas/classic-watchdog

The testing done here doesn't appear to be functional testing (which we would usually require for a merge), however the minor patch version increment should not include any breaking changes, so I am open to merging it without further testing.

Alex

@Jack64
Copy link

Jack64 commented May 5, 2022

For any concerned users, we must ask: "What is the likelihood of this being a risk for your environment?" It sounds like this only affects users who directly expose the expose the Prometheus HTTP server on the Internet? By default we run the Prometheus server on a separate private port, which is only available in-cluster. The risk should be extremely low for most users. If you see it differently, let me know.

This is a good question. The risk assessment you provided has multiple assumptions:

  • The user did not expose prometheus
  • There is a service mesh in place, properly configured, preventing access from unauthorized services to the prometheus servers
  • There are no SSRF (Server-Side Request Forgery) vulnerabilities anywhere in the cluster allowing the internal request (causing the DoS) to be sent
  • The developers with kubeconfig proxy capabilities / VPN access to the vulnerable services have not been compromised

If these assumptions do not hold true, then the risk may not be "extremely low" -- combine this with the easy fix of just upgrading the dependency to the latest patch version, it seems like an easy decision to merge here and in other affected components.

@alexellis
Copy link
Member

Thanks for your comment @Jack64.

combine this with the easy fix of just upgrading the dependency to the latest patch version, it seems like an easy decision to merge here and in other affected components

I don't disagree, that's what my intention was when I responded above.

Out of curiosity, are you also an openfaas user or a colleague of Hilario?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants