Description of problem (please be detailed as possible and provide log snippests): Previous slack discussion (IBM slack #cae-team-collaboration channel) regarding CVE-2023-38408 indicated that this vulnerability should be fixed in the next update of ODF (4.12.8 was released on 9/27/2023). Based on what was said in slack (screenshot has now been deleted), this is the information relayed to the customer : ~~~ Engineering has described their build process when a new ODF version is released. Before a new ODF version is laid down on the underlying ubi8 container image, the container image is first updated (e.g. dnf update) and then the new ODF code is placed on top of the container. Thus, the ODF 4.12.8 containers should contain those openssh fixes for CVE-2023-38408. ~~~ After updating to OCP 4.12.35 and ODF 4.12.8, the customer finds that they are still vulnerable to CVE-2023-38408 Version of all relevant components (if applicable): This is my versions from clusterbot but matches the customers versions in case TS014156544 ~~~ $ oc get clusterversion;oc get csv; NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.12.35 True False 9m35s Cluster version is 4.12.35 NAME DISPLAY VERSION REPLACES PHASE mcg-operator.v4.12.8-rhodf NooBaa Operator 4.12.8-rhodf mcg-operator.v4.12.7-rhodf Succeeded ocs-operator.v4.12.8-rhodf OpenShift Container Storage 4.12.8-rhodf ocs-operator.v4.12.7-rhodf Succeeded odf-csi-addons-operator.v4.12.8-rhodf CSI Addons 4.12.8-rhodf odf-csi-addons-operator.v4.12.7-rhodf Succeeded odf-operator.v4.12.8-rhodf OpenShift Data Foundation 4.12.8-rhodf odf-operator.v4.12.7-rhodf Succeeded ~~~ Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? Customer is in danger of falling out of compliance with open violations where the CVSS >=9 Is there any workaround available to the best of your knowledge? Not known Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? 1 Can this issue reproducible? yes Can this issue reproduce from the UI? yes If this is a regression, please provide more details to justify this: Steps to Reproduce: 1. using cluster bot, launch a 4.12.35 cluster "launch 4.12.35 aws,xlarge" 2. install the ODF operator and then the storage cluster. 3. Once all the ODF related pods come up and the cluster is healthy, verify the versions on the nodes/inside the pods a. 'oc debug node/X -- rpm -qa |grep openssh' b. 'oc rsh rook-ceph* rpm -qa |grep openssh' Actual results: Node level: ~~~ $ oc debug node/ip-10-0-204-217.us-west-1.compute.internal -- rpm -qa |grep openssh Temporary namespace openshift-debug-l268q is created for debugging node... Starting pod/ip-10-0-204-217us-west-1computeinternal-debug ... To use host binaries, run `chroot /host` openssh-clients-8.0p1-15.el8_6.x86_64 openssh-8.0p1-15.el8_6.x86_64 ~~~ Pod level : ~~~ $ for i in $(oc get pods -o wide |grep ^rook-ceph|grep -v prepare|awk '{print $1}'); do echo $i; oc rsh $i rpm -qa |grep openssh; done rook-ceph-crashcollector-384c8773f444b2dab41b30c101699d0e-smdtl Defaulted container "ceph-crash" out of: ceph-crash, make-container-crash-dir (init), chown-container-data-dir (init) openssh-8.0p1-17.el8_7.x86_64 openssh-clients-8.0p1-17.el8_7.x86_64 rook-ceph-crashcollector-7f10271c7c2b06241b5f9ea34c05a67a-5l7rj Defaulted container "ceph-crash" out of: ceph-crash, make-container-crash-dir (init), chown-container-data-dir (init) openssh-8.0p1-17.el8_7.x86_64 openssh-clients-8.0p1-17.el8_7.x86_64 rook-ceph-crashcollector-baf349f64060b968d8d4ba90e0aba295-rm2qg Defaulted container "ceph-crash" out of: ceph-crash, make-container-crash-dir (init), chown-container-data-dir (init) openssh-8.0p1-17.el8_7.x86_64 openssh-clients-8.0p1-17.el8_7.x86_64 rook-ceph-mds-ocs-storagecluster-cephfilesystem-a-54dfc595t79c8 Defaulted container "mds" out of: mds, log-collector, chown-container-data-dir (init) Error from server (BadRequest): pod rook-ceph-mds-ocs-storagecluster-cephfilesystem-a-54dfc595t79c8 does not have a host assigned rook-ceph-mds-ocs-storagecluster-cephfilesystem-b-7f976f56ltrd9 Defaulted container "mds" out of: mds, log-collector, chown-container-data-dir (init) Error from server (BadRequest): pod rook-ceph-mds-ocs-storagecluster-cephfilesystem-b-7f976f56ltrd9 does not have a host assigned rook-ceph-mgr-a-c4886d9c7-zgpj5 Defaulted container "mgr" out of: mgr, log-collector, chown-container-data-dir (init) openssh-8.0p1-17.el8_7.x86_64 openssh-clients-8.0p1-17.el8_7.x86_64 rook-ceph-mon-a-58cc8b955f-vd4lk Defaulted container "mon" out of: mon, log-collector, chown-container-data-dir (init), init-mon-fs (init) openssh-8.0p1-17.el8_7.x86_64 openssh-clients-8.0p1-17.el8_7.x86_64 rook-ceph-mon-b-5577dcfbdf-fnrb6 Defaulted container "mon" out of: mon, log-collector, chown-container-data-dir (init), init-mon-fs (init) openssh-8.0p1-17.el8_7.x86_64 openssh-clients-8.0p1-17.el8_7.x86_64 rook-ceph-mon-c-549ffb6575-ndlwm Defaulted container "mon" out of: mon, log-collector, chown-container-data-dir (init), init-mon-fs (init) openssh-8.0p1-17.el8_7.x86_64 openssh-clients-8.0p1-17.el8_7.x86_64 rook-ceph-operator-56f69c4547-mt7p5 openssh-8.0p1-19.el8_8.x86_64 openssh-clients-8.0p1-19.el8_8.x86_64 rook-ceph-osd-0-79d58b8b67-sszv6 Defaulted container "osd" out of: osd, log-collector, blkdevmapper (init), activate (init), expand-bluefs (init), chown-container-data-dir (init) openssh-8.0p1-17.el8_7.x86_64 openssh-clients-8.0p1-17.el8_7.x86_64 rook-ceph-osd-1-5497c6b679-8ppn5 Defaulted container "osd" out of: osd, log-collector, blkdevmapper (init), activate (init), expand-bluefs (init), chown-container-data-dir (init) openssh-8.0p1-17.el8_7.x86_64 openssh-clients-8.0p1-17.el8_7.x86_64 rook-ceph-osd-2-68c656988f-nllc4 Defaulted container "osd" out of: osd, log-collector, blkdevmapper (init), activate (init), expand-bluefs (init), chown-container-data-dir (init) openssh-8.0p1-17.el8_7.x86_64 openssh-clients-8.0p1-17.el8_7.x86_64 ~~~ Expected results: Expected to see the fixed versions (e.g. openssh-8.0p1-19.el8_8.x86_64.rpm) reported on the errata link https://access.redhat.com/errata/RHSA-2023:4419 Additional info:
This is just about updating the rhceph image. As such, I'm closing this as a duplicate of 4.12.z bz to update the rhceph image. *** This bug has been marked as a duplicate of bug 2244765 ***