Skip to content
This repository has been archived by the owner on Oct 22, 2021. It is now read-only.

CAPI logs service broker credentials (CVE-2021-22115) #1732

Open
jbuns opened this issue May 26, 2021 · 2 comments
Open

CAPI logs service broker credentials (CVE-2021-22115) #1732

jbuns opened this issue May 26, 2021 · 2 comments
Assignees
Labels
Type: Bug Something isn't working

Comments

@jbuns
Copy link
Collaborator

jbuns commented May 26, 2021

Describe the bug
As per the CVE's description:

Cloud Controller API versions prior to 1.106.0 logs service broker credentials if the default value of db logging config field is changed. CAPI database logs service broker password in plain text whenever a job to clean up orphaned items is run by Cloud Controller. A malicious user with access to those logs may gain unauthorised access to service broker.

https://www.cloudfoundry.org/blog/cve-2021-22115-capi-logs-service-broker-credentials/

To Reproduce
N/A

Expected behavior
CAPI shouldn't log service broker credentials

Environment

  • CAPI
    • All versions prior to 1.106.0
  • CF Deployment
    • All versions prior to 16.2.0

The latest version of KubeCF 2.7.13 is currently using

- name: capi
  url: https://bosh.io/d/github.com/cloudfoundry/capi-release?v=1.98.0
  version: 1.98.0
  sha1: e4b0b8a1ef10b71da5b09248150c3295197ee0b6

Additional context
Add any other context about the problem here.

@jbuns jbuns added the Type: Bug Something isn't working label May 26, 2021
@jbuns
Copy link
Collaborator Author

jbuns commented May 26, 2021

Looks like fix is already planned here:
#1730

@jandubois
Copy link
Member

@jbuns I've looked at this CVE before, but think it is really a low priority for kubecf because of:

if the default value of db logging config field is changed

kubecf doesn't change the default value, and doesn't expose a simple way to modify it, so standard deployments are unaffected. And the workaround to fix this is simply to revert the db logging field to its default value. This is really a debugging setting which should typically not be enabled in a production environment.

We will of course address this automatically whenever we do another release, which will bump cf-deployment. This was mostly held up because we lost CI for the last 6 weeks or so. It is back now, but upgrade tests are still problematic and may need some pipeline work.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Type: Bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants