Address security vulnarabilities in the image/binary/repo #3538
Comments
|
Except for the CVEs in The Vault ones look related to the server only, not to the API/client? |
nixpanic
added
question
|
Besides mentioned CVEs for Hashicorp, there is a newer one: CVE-2022-36129 (9.1 Critical): https://cve.report/CVE-2022-36129 Fixed in 1.11.1, 1.10.5, and 1.9.8 - https://discuss.hashicorp.com/t/vault-1-11-1-1-10-5-and-1-9-8-released/42389 |
|
On Tue, Nov 22, 2022 at 11:35:32AM -0800, Vladimir Markelov wrote:
Besides mentioned CVEs for Hashicorp, there is a newer one: CVE-2022-36129 (9.1 Critical): https://cve.report/CVE-2022-36129
Fixed in 1.11.1, 1.10.5, and 1.9.8 - https://discuss.hashicorp.com/t/vault-1-11-1-1-10-5-and-1-9-8-released/42389
This CVE seems only applicable for the Vault server. Ceph-CSI uses the
Vault client API only, so it is not affected.
|
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions. |
|
This issue has been automatically closed due to inactivity. Please re-open if this still requires investigation. |
It is possible update the packages from the Dockerfile... Updating it in the base image is better and smaller, but that works.... |
@mohag we do that here already ? https://github.com/ceph/ceph-csi/blob/devel/deploy/cephcsi/image/Dockerfile#L31 or you mean something we are missing ? |
Like that yes, but in the release image (somewhere under line 59) as well (that one is in the build image) |
|
@mohag we can do that as well. do you want to submit a PR ? or I can do that. please let me know. |
I'll attempt a PR. |
|
A big part of the issue with the OS packages here is that the quay.io/centos/centos:8stream image seems to not be routinely updated. (the quay.io/ceph/ceph image uses that as a base) (It should be rebuilt every time an update to a package in that image is available. I could not track down the repo where those Dockerfiles are kept to try and nag them though) |
|
This is probably the one you're looking for: https://github.com/tgagor/docker-centos/blob/master/stream8/Dockerfile Update: Nevermind, this wasn't the original image but an image that has a built-in update. |
|
Let's see if we can get the underlying base images upgraded.... |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions. |
|
The base images have been upgraded |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions. |
|
This issue has been automatically closed due to inactivity. Please re-open if this still requires investigation. |
|
Can we get this re-opened? Joblib in particular in the ceph-csi image raises a cve score of 9.8 https://avd.aquasec.com/nvd/2022/cve-2022-21797/ Seems potentially worth looking at since it's vulnerable to arbitrary code execution. I'm running v3.11.0 which seems to be the newest version, and is still vulnerable to this. |
Considering most of the vulnerabilities are in base image, thats the place we have to look into |
|
If it's not a necessary dependency, the option of uninstalling it from the image in the Dockerfile here is an option that is available as well. If it is a necessary dependency, there's not much to really do (maybe look for alternatives) since there's apparently no patched version. I understand that the maintainers of ceph-csi might find that to be less than a "clean" solution. But ceph-csi is a product that is only expected to be ran in a container. So hardening the production image everyone uses seems like it shouldn't be an incredibly tall order for this project to take on, imho, even if it's a stopgap to getting the fix in the upstream base image. Certainly not such a tall order that a 9.8 score CVE stays in the production image for a year and a half (the approximate age of this issue.) I'd even be happy to try my hand at helping contribute this fix if the maintainers here are open to the fix being implemented here. I mean... it's an arbitrary code execution vulnerability in an image running as root in my clusters with host mode networking and touches my storage clusters. I feel like that sounds like a pretty important thing to tighten up. If I'm being melodramatic let me know, but it seems like something worth acting on last year. That all being said, I'm extremely grateful for the tool, both this cluster client, and ceph in general are amazing. Absolutely wanted to underscore I'm not undermining the awesomeness of it, I just want it to be awesome and actually reasonably secure to run. |
|
If ceph-csi's maintainers are dead set on the vulnerability resolution being implemented in the upstream container, can we get a link to the Issue tracking it upstream over here? I'd very much appreciate it! |
|
@Starttoaster Issues like : ceph/ceph-container#2077 try to cover this request. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions. |
|
Still not stale. Relevant here but still tracking in ceph-container as well |
Rakshith-R
added
the
keepalive
|
This might be somewhat solved now. There's still a critical vulnerability but now it's just from slightly out of date Go dependencies, since this switched to a base CentOS Stream 9 image. Thanks @Madhu-1 !! |
|
Closing this one as we have updated to use centos 9 image. @Starttoaster Thanks for checking, feel free to open issue for go dependencies :) |
Describe the bug
We are getting many reports against Ceph CSI image and the vulnerabilities it hold. it is required/better to address as much as we can.
as part of this effort I have started enabling trvivy scanner in the repo via #3537 and initial report says
The text was updated successfully, but these errors were encountered: