ManageIQ/kubeclient

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

cben opened this issue · 10 comments

cben commented

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.

cben commented

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 commented

@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 commented

✔️ 4.9.3 released on rubygems.

cben commented

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?

mend-bolt-for-github commented

✔️ 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 commented

@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 commented

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

Fryguy commented

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 commented

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 commented

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 ✔️

  • 👍1