Description of problem: From PSIRT-413, security review of CBO: The baremetalMachineOsDownloader component downloads in an insecure way the RHCOS images. It should be corrected and also confirmed where the RHCOS images are downloaded from. We should inject the additional trust bundle from the installer to ensure user certificates are verified, and remove the --insecure flag. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Could you, please, advise how to verify this?
Hi. This is an interesting question. Since the metal3-machine-os-downloader pod is an init container, you will not be able to login into it and test curl. The closest thing you can do is probably go to any one of the currently active metal3 containers and download the rhcos file which the metal3-machine-os-downloader container downloads. Make sure you don't pass the --insecure flag to curl. The fact that the CA trust bundle exists in the metal3 pod, means that curl (without the --insecure flag) works correctly. [~/git/dev-scripts]$ oc get pods -n openshift-machine-api NAME READY STATUS RESTARTS AGE cluster-autoscaler-operator-8878489f4-mnlrn 2/2 Running 0 23h cluster-baremetal-operator-f58f65496-xg48k 2/2 Running 0 23h machine-api-controllers-556b546fb6-cvzx5 7/7 Running 3 23h machine-api-operator-7c76696f5c-qt22x 2/2 Running 0 23h metal3-648dbd4797-58d22 10/10 Running 0 81m metal3-image-cache-c5sh7 1/1 Running 0 23h metal3-image-cache-ghgqz 1/1 Running 0 23h metal3-image-cache-tqb2b 1/1 Running 0 23h [~/git/dev-scripts]$ oc rsh -n openshift-machine-api metal3-648dbd4797-58d22 Defaulting container name to metal3-baremetal-operator. Use 'oc describe pod/metal3-648dbd4797-58d22 -n openshift-machine-api' to see all of the containers in this pod. sh-4.4# cd /tmp sh-4.4# curl http://192.168.111.1/images/rhcos-48.83.202103221318-0-openstack.x86_64.qcow2.gz?sha256=323e7ba4ba3448e340946543c963823136e1367ed0b229d2a05e1cf537642bb8 --output curlfile % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 898M 100 898M 0 0 873M 0 0:00:01 0:00:01 --:--:-- 873Ml sh-4.4# ls -al curlfile -rw-r--r--. 1 root root 942011087 Apr 6 19:05 curlfile sh-4.4# rm -f curlfile sh-4.4# exit [~/git/dev-scripts]$
> sh-4.4# cd /tmp > sh-4.4# curl > http://192.168.111.1/images/rhcos-48.83.202103221318-0-openstack.x86_64. > qcow2. > gz?sha256=323e7ba4ba3448e340946543c963823136e1367ed0b229d2a05e1cf537642bb8 > --output curlfile > % Total % Received % Xferd Average Speed Time Time Time > Current > Dload Upload Total Spent Left Speed > 100 898M 100 898M 0 0 873M 0 0:00:01 0:00:01 --:--:-- > 873Ml The URL listed here is not https, in a connected environment, we can try downloading the rhcos URL (which can be constructed from the openshift/installer/data/data/rhcos.json file. e.g. curl -L https://releases-art-rhcos.svc.ci.openshift.org/art/storage/releases/rhcos-4.8/48.83.202103221318-0/x86_64/rhcos-48.83.202103221318-0-openstack.x86_64.qcow2.gz -o rhcos-file
As we discussed on slack, in disconnected env it's enough to ensure the cert bundle exists inside the metal3 pod Verified on 4.8.0-0.nightly-2021-04-06-162113 [kni@provisionhost-0-0 ~]$ oc rsh metal3-7b6f795df-fftfw sh-4.4# ls -l /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem lrwxrwxrwx. 1 root root 24 Apr 7 08:17 /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem -> ..data/tls-ca-bundle.pe
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.8.2 bug fix and security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:2438