CVE-2022-0759 VULNERABILITY: `Config` defaults to `VERIFY_NONE` when kubeconfig doesn't specify custom CA - autoclosed #554

cben · 2022-03-23T10:28:21Z

this was assigned CVE-2022-0759

Dangerous bug present ever since Kubeclient::Config was created:

Whenever kubeconfig did not define custom CA (normal situation for production clusters with public domain and certificate!), Config was returning ssl_options[:verify_ssl] hard-coded to VERIFY_NONE :-(

Assuming you passed those ssl_options to Kubeclient::Client, this means that instead of checking server's certificate against your system CA store, it would accept ANY certificate, allowing easy man-in-the middle attacks.

This is especially dangerous with user/password or token credentials because MITM attacker could simply steal those credentials to the cluster and do anything you could do on the cluster.

Tightly related to #555, I'm fixing them together. This ticket is about the dangerous default, #555 is about inability to override it.

The text was updated successfully, but these errors were encountered:

cben · 2022-03-23T10:28:55Z

This was broken IN ALL RELEASES MADE BEFORE 2022. I'm releasing a 4.9.3 with fix today.
Anyone who needs backports to other versions, let me know

cben · 2022-03-23T11:14:42Z

@lnacshonredhat (or anyone else who knows): can you help describe the impact when using client-certificate auth? My partial understanding:

An attack on the app using kubeclient is still possible.
Attacker can still fool kubeclient by returning made-up responses, it doesn't need 2nd connection to real cluster (because the client doens't verify the servers's identity).
- This way attacker may get from kubeclient content of any resources kubeclient writes, e.g. if kubeclient is used to create/update secrets those will leak ☹️.
However, the client cert's secret key is not sent, so attacker cannot steal the credentials for later use, only risks are during the active attack.
The server does verify client's identity! 😅
What degree of man-in-the-middle attack is possible?
- Obviously attacker pass through the data byte-for-byte both ways (kubeclient⭤MITM⭤real cluster), but that's what any internet router does, so attacker can't decrypt.
- Can attacker relay the inner HTTP protocol unmodified AND decrypt it? Or does decryption require changing the certs in a way that will make the cluster reject the TLS connection?
- Can can attacker execute any action on the cluster different from kubeclient requested?
- Can attacker switch from exact relaying to modifying anything mid-way?

cben · 2022-03-23T12:09:27Z

✔️ 4.9.3 released on rubygems.

Tiny followup to ManageIQ#556. Sorry for noise, had these locally but forgot to push before merging. If I start backporting, CHANGELOG.md on master branch might not always be updated with all backports (it SHOULD, but it will require separate merges to master). So I prefer pointing to the vulnerability issue as the "source of truth". Also, security impact will be better discussed on the issue.

…ngelog fixup CHANGELOG and README about #554, #555

@rockb1017

See ManageIQ/kubeclient#554, I fixed an embarrasing vulnerability in Kubeclient::Config — it could wrongly set `VERIFY_NONE`, allowing man-in-the-middle attacks and stealing cluster credentials 😳 And I see this repo does use `Kubeclient::Config.read`. kubeclient generally obeys SemVer, so upgrading 4.6.z to 4.9.z should be safe. OTOH if you think upgrading is tricky, let us know on that kubeclient issue, we can backport the fix! @harshit-splunk @rockb1017 I see several of fluent-plugin-* gems depend on '~> 4.6.0', and more than one are maintained by Splunk — I'm not going to send PRs to them all, please spread the word.

cben · 2022-03-25T14:21:59Z

Do we need more backports?
Found this way to graph what versions are getting pulled in practice over time, e.g. these graphs are over last two days: https://ui.honeycomb.io/ruby-together/datasets/rubygems.org/result/i7SSSySDaHJ
I see non-negligible downloads of 4.6.0 and 4.7.0 that do not upgrade automatically to 4.9.z. I also peeked at https://rubygems.org/gems/kubeclient/reverse_dependencies, and saw very few = dependencies, but quite a few dependencies that fix the minor version e.g. ~> 4.6.0.

So I'm thinking releasing 4.6.1 and 4.7.1 may be useful? (and then maybe 4.8.1 just to avoid situation where upgrading causes regression?)

I also see some really old versions like 1.1.4 still getting used. Somewhat silly, but the fix commit itself (without tests) is trivially backportable. How far should I go?

Hi, I see your code uses `Kubeclient::Config.read("#{ENV['HOME']}/.kube/config")`. 4.9.3 fixed a severe issue in Config — ManageIQ/kubeclient#554 I did not test this but generally kubeclient obeys semver, AFAIK 4.9 remains backwards-compatible with 4.1.

Hi, I see your code uses `Kubeclient::Config.read(ENV['KUBECONFIG'])`. 4.9.3 fixed a severe issue in Config, in some scenarios causing insecure VERIFY_NONE connections that may leak cluster credentials — ManageIQ/kubeclient#554 Your dependency range already allowed 4.9.3 but it's safer to disallow the older versions.

4.9.3 fixed [CVE-2022-0759 in `Kubeclient::Config`](ManageIQ/kubeclient#554), which I see you do use, at least in `create_client_from_config`. Current "~> 4.3" range already allows 4.9.x but safer to force it as minimum.

mend-bolt-for-github · 2022-05-30T02:51:41Z

✔️ This issue was automatically closed by Mend because the vulnerable library in the specific branch(es) was either marked as ignored or it is no longer part of the Mend inventory.

cben · 2022-05-30T10:49:48Z

@agrare is this "Mend" bot part of the standard setup in manageiq org?
IMHO a bot closing a vulnerability issue with a generic "either ... or ..." without specific details is more harmful than useful. In first case, where was it marked ignored, and by whom? In 2nd case, what is Mend's inventory, and why the library(?) being dropped from it justifies closing the library's github issue?

In this case, the issue has been fixed in a released version of kubeclient, so we can keep this closed.
4.9.2 to this day has much more downloads than 4.9.3 which is discouraging but I can't do anything about that... Probably lots of apps have a Gemfile.lock.

agrare · 2022-05-30T11:18:58Z

@cben I haven't seen the mend-bolt-for-github before, @Fryguy looks like this has something to do with whitesource scans?

Fryguy · 2022-06-06T13:36:40Z

Yes, mend is the new name for whitesource, so this is the whitesource bot - I'm as surprised as you are that they closed an issue they didn't own. I presume because it said CVE-2022-0759 in the title, but that's not a very good reason. I'm going to open a support ticket with them.

In this case, the issue has been fixed in a released version of kubeclient, so we can keep this closed.

We can reopen if you want...it's up to you

zeisss · 2022-08-30T13:27:25Z

Can we add this issue / release to the CHANGELOG.md?

Edit: Nevermind, I see that this is an older issue. I was trying to find our what changed in 4.10.0 ...

cben · 2022-08-31T06:56:02Z

Thes one i believe is covered in https://github.com/ManageIQ/kubeclient/blob/master/CHANGELOG.md#493-2021-03-23

4.10 - ah good catch, it's only described on v4.y branch:
https://github.com/ManageIQ/kubeclient/blob/v4.y/CHANGELOG.md#4100--2022-08-29
Let me fix that.... FIXED ✔️

cben added bug Mend: dependency security vulnerability Security vulnerability detected by WhiteSource labels Mar 23, 2022

This was referenced Mar 23, 2022

Config ignores insecure-skip-tls-verify field #555

Closed

[v4.y] SECURITY: Kubeclient::Config: return ssl_options[:verify_ssl] correctly #556

Merged

This was referenced Mar 23, 2022

SECURITY: Kubeclient::Config: return ssl_options[:verify_ssl] correctly #557

Merged

Releasing 4.9.3 #558

Merged

Kubeclient does not support certificate authorities with intermediate certificate #460

Open

cben added a commit that referenced this issue Mar 23, 2022

Merge pull request #559 from cben/v4.y-security-config-ssl_verify-cha…

2d241e3

…ngelog fixup CHANGELOG and README about #554, #555

cben mentioned this issue Mar 23, 2022

updating from 4.9 to master breaks ssl #525

Closed

cben mentioned this issue Mar 25, 2022

Update dependency for Kubeclient::Config vulnerability splunk/fluent-plugin-kubernetes-metrics#115

Closed

8 tasks

cben changed the title ~~VULNERABILITY: Config defaults to VERIFY_NONE when kubeconfig doesn't specify custom CA~~ CVE-2022-0759 VULNERABILITY: Config defaults to VERIFY_NONE when kubeconfig doesn't specify custom CA Mar 27, 2022

cben mentioned this issue Apr 12, 2022

Update kubeclient requirement from = 4.1.0 to = 4.9.3 nanit/eks_cli#11

Closed

cben mentioned this issue Apr 12, 2022

Ensure kubeclient >= 4.9.3 to avoid CVE-2022-0759 voxpupuli/beaker-gke#15

Open

cben mentioned this issue May 11, 2022

Bump kubeclient >= 4.9.3 to avoid Kubeclient::Config vulnerability fog/fog-kubevirt#153

Merged

mend-bolt-for-github bot changed the title ~~CVE-2022-0759 VULNERABILITY: Config defaults to VERIFY_NONE when kubeconfig doesn't specify custom CA~~ CVE-2022-0759 VULNERABILITY: Config defaults to VERIFY_NONE when kubeconfig doesn't specify custom CA - autoclosed May 30, 2022

mend-bolt-for-github bot closed this as completed May 30, 2022

billthompson mentioned this issue Mar 6, 2023

Add support for Ruby 3.0 keylimetoolbox/resque-kubernetes#30

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CVE-2022-0759 VULNERABILITY: `Config` defaults to `VERIFY_NONE` when kubeconfig doesn't specify custom CA - autoclosed #554

CVE-2022-0759 VULNERABILITY: `Config` defaults to `VERIFY_NONE` when kubeconfig doesn't specify custom CA - autoclosed #554

cben commented Mar 23, 2022 •

edited

Loading

cben commented Mar 23, 2022

cben commented Mar 23, 2022

cben commented Mar 23, 2022

cben commented Mar 25, 2022

mend-bolt-for-github bot commented May 30, 2022

cben commented May 30, 2022

agrare commented May 30, 2022

Fryguy commented Jun 6, 2022 •

edited

Loading

zeisss commented Aug 30, 2022 •

edited

Loading

cben commented Aug 31, 2022 •

edited

Loading

CVE-2022-0759 VULNERABILITY: Config defaults to VERIFY_NONE when kubeconfig doesn't specify custom CA - autoclosed #554

CVE-2022-0759 VULNERABILITY: Config defaults to VERIFY_NONE when kubeconfig doesn't specify custom CA - autoclosed #554

Comments

cben commented Mar 23, 2022 • edited Loading

this was assigned CVE-2022-0759

cben commented Mar 23, 2022

cben commented Mar 23, 2022

cben commented Mar 23, 2022

cben commented Mar 25, 2022

mend-bolt-for-github bot commented May 30, 2022

cben commented May 30, 2022

agrare commented May 30, 2022

Fryguy commented Jun 6, 2022 • edited Loading

zeisss commented Aug 30, 2022 • edited Loading

cben commented Aug 31, 2022 • edited Loading

CVE-2022-0759 VULNERABILITY: `Config` defaults to `VERIFY_NONE` when kubeconfig doesn't specify custom CA - autoclosed #554

CVE-2022-0759 VULNERABILITY: `Config` defaults to `VERIFY_NONE` when kubeconfig doesn't specify custom CA - autoclosed #554

cben commented Mar 23, 2022 •

edited

Loading

Fryguy commented Jun 6, 2022 •

edited

Loading

zeisss commented Aug 30, 2022 •

edited

Loading

cben commented Aug 31, 2022 •

edited

Loading