USB CVE-2024-53104 Mitigation for OpenShift
CVE-2024-53104 documents a vulnerability found in the Linux kernel's USB Video Class driver. The vulnerability exists in functionality used by the USB Video Class driver to decode the format of video frames. An attacker who is able to influence the format of video streams captured by a system's USB video device could exploit this flaw to alter system memory and potentially escalate their privileges or execute arbitrary code.
While Red Hat is prioritizing and plans to ship z-stream updates for all supported OpenShift Container Platform releases over the next two weeks, there are actions you can take to mitigate the possibility of an attack before those updates ship.
Note that if you have installed the OpenShift Compliance operator and applied remediation for the rhcos4-moderate or rhcos4-high profiles, USB access to your nodes is already prevented.
Blocking the uvcvideo kernel module via MachineConfig
If your OpenShift cluster does not use uvcvideo kernel module we recommend mitigating the flaw by preventing the uvcvideo module from loading as shown below. Note that disabling this module will prevent UVC devices such as webcams or video capture devices from functioning properly.
The MachineConfig code below will inhibit loading the uvcvideo kernel module on workers and will trigger a rolling restart of workers.
1. Create YAML file 99-worker-deny-uvcvideo.yaml with the following content:
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: worker
name: 99-worker-deny-uvcvideo
spec:
config:
ignition:
version: 3.2.0
storage:
files:
- contents:
compression: ""
source: data:,blacklist%20uvcvideo%0Ainstall%20uvcvideo%20%2Fbin%2Ffalse%0A
mode: 420
overwrite: true
path: /etc/modprobe.d/ocp-deny-uvcvideo.conf
2. Apply this config by running oc apply as an admin:
$ oc apply -f 99-worker-deny-uvcvideo.yaml
machineconfig.machineconfiguration.openshift.io/99-worker-deny-uvcvideo created
3. If you also wish to protect your control plane nodes, create a similar MachineConfig with
machineconfiguration.openshift.io/role: “master”.
Blocking the uvcvideo kernel module via Compliance Operator Profiles
Another option to mitigate the issue in the meanwhile is by using Compliance Operator profiles.
You can choose to modify your node configurations using existing Compliance Operator profiles or by creating a tailored profile. To use this method, you must first install the Compliance Operator on your Cluster. To disable the use of USB devices, you can run the rhcos4-moderate or rhcos4-high profiles.
If you only want to disable uvcvideo you can create a tailored profile instead as shown below which will disable only uvcvideo. Here are the steps:
1. Create a YAML file deny-uvc-profile.yaml for the TailoredProfile:
apiVersion: compliance.openshift.io/v1alpha1
kind: TailoredProfile
metadata:
name: deny-uvc-profile
namespace: openshift-compliance
annotations:
## We need to set product type to Node for rhcos4 profile rules
compliance.openshift.io/product-type: Node
spec:
description: a profile will check if uvcvideo module is disabled
enableRules:
- name: rhcos4-kernel-module-uvcvideo-disabled
rationale: CVE-2024-53104 documents a vulnerability found in the Linux kernel's USB Video Class driver. The vulnerability exists in functionality used by the USB Video Class driver to decode the format of video frames.
title: Ensure uvcvideo module is being disabled
Run to apply:
$ oc apply -f deny-uvc-profile.yaml
2. Create ScanSettingBinding YAML file deny-uvc-ssb.yaml that referencea the created TailoredProfile:
apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
name: deny-uvc-ssb
namespace: openshift-compliance
profiles:
## you can include this TailoredProfile with other existing profiles
## in a ScanSettingBinding you are already using or create a new one
- apiGroup: compliance.openshift.io/v1alpha1
kind: TailoredProfile
name: deny-uvc-profile
settingsRef:
apiGroup: compliance.openshift.io/v1alpha1
kind: ScanSetting
# Use the default-auto-apply will automatically apply the generated remediation otherwise # if you want to apply remediation manually you use default ScanSetting here
# adjust and create ScanSetting to let operator know what pool you want to apply the Scan # and remediation to, we have master, worker role as default
name: default-auto-apply
Run to apply:
$ oc apply -f deny-uvc-ssb.yaml
3. Check we have TailoredProfile and ScanSettingBinding in Ready States like below:
$ oc get tp
NAME STATE
deny-uvc-profile READY
$ oc get ssb
NAME STATUS
deny-uvc-ssb READY
4. Wait for scan to finish and remediation to be applied
$ oc get scan
NAME PHASE RESULT
deny-uvc-profile-master DONE NON-COMPLIANT
deny-uvc-profile-worker DONE NON-COMPLIANT
$oc get ccr
NAME STATUS SEVERITY
deny-uvc-profile-master-kernel-module-uvcvideo-disabled FAIL medium
deny-uvc-profile-worker-kernel-module-uvcvideo-disabled FAIL medium
We can see that compliance remediation has been generated and applied to the cluster
$ oc get cr
NAME STATE
deny-uvc-profile-master-kernel-module-uvcvideo-disabled Applied
deny-uvc-profile-worker-kernel-module-uvcvideo-disabled Applied
We can inspect the generated ComplianceRemediaiton:
$ oc get cr -o yaml
apiVersion: v1
items:
- apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceRemediation
metadata:
creationTimestamp: "2025-02-10T23:33:44Z"
generation: 2
labels:
compliance.openshift.io/scan-name: deny-uvc-profile-master
compliance.openshift.io/suite: deny-uvc-ssb
name: deny-uvc-profile-master-kernel-module-uvcvideo-disabled
namespace: openshift-compliance
spec:
apply: true
current:
object:
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
config:
ignition:
version: 3.1.0
storage:
files:
- contents:
source: data:,install%20uvcvideo%20/bin/false%0Ablacklist%20uvcvideo%0A
mode: 420
overwrite: true
path: /etc/modprobe.d/uvcvideo.conf
outdated: {}
type: Configuration
status:
applicationState: Applied
We will wait for all the nodes to be updated:
~ % oc get mcp
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
master rendered-master-2d509f401a173fe88c986bbfb94443e3 True False False 3 3 3 0 63m
worker rendered-worker-c0e83d6064f20d73d77adea67e4ce254 False True False 3 1 3 0 63m
5. We can rerun the ComplianceScan to check if the remediation has taking effects:
$ oc compliance rerun-now scansettingbindings deny-uvc-ssb
Rerunning scans from 'deny-uvc-ssb': deny-uvc-profile-master, deny-uvc-profile-worker
Re-running scan 'openshift-compliance/deny-uvc-profile-master'
Re-running scan 'openshift-compliance/deny-uvc-profile-worker'
We can see that all the scan are now in passing state:
$ oc get scan
NAME PHASE RESULT
deny-uvc-profile-master DONE COMPLIANT
deny-uvc-profile-worker DONE COMPLIANT
$ oc get ccr
NAME STATUS SEVERITY
deny-uvc-profile-master-kernel-module-uvcvideo-disabled PASS medium
deny-uvc-profile-worker-kernel-module-uvcvideo-disabled PASS medium
Optionally we can check on each node as well:
$ oc debug node/ip-10-0-xxx-xx.us-west-1.compute.internal
Temporary namespace openshift-debug-24ngm is created for debugging node...
Starting pod/ip-10-0-xxx-xx.us-west-1computeinternal-debug-q4chx ...
To use host binaries, run `chroot /host`
Pod IP: 10.0.xxx.xx
If you don't see a command prompt, try pressing enter.
sh-5.1# chroot /host
sh-5.1# cat /etc/modprobe.d/uvcvideo.conf
install uvcvideo /bin/false
blacklist uvcvideo
sh-5.1# modprobe uvcvideo
modprobe: ERROR: Error running install command '/bin/false' for module uvcvideo: retcode 1
modprobe: ERROR: could not insert 'uvcvideo': Invalid argument
sh-5.1# lsmod | grep uvcvideo
Note about USBGuard
When you use the rhcos4-moderate and rhcos4-high profile, the following rules are part of the profiles and they enable and configure USBGguard:
- rhcos4-package-usbguard-installed
- rhcos4-service-usbguard-enabled
- rhcos4-configure-usbguard-auditbackend
- rhcos4-usbguard-allow-hid-and-hub
You can either run a scan for one of those profiles and apply the remediations or use them in a tailoredProfile, following the example above. USBGuard could be an additional protection layer.
This would be the YAML file:
apiVersion: compliance.openshift.io/v1alpha1
kind: TailoredProfile
metadata:
name: enable-usbguard-tp
namespace: openshift-compliance
annotations:
## We need to set product type to Node for rhcos4 profile rules
compliance.openshift.io/product-type: Node
spec:
description: a profile will check if uvcvideo module is disabled
enableRules:
- name: rhcos4-package-usbguard-installed
rationale: we need to check and install usbguard
- name: rhcos4-service-usbguard-enabled
rationale: usbguard will be installed after install
- name: rhcos4-configure-usbguard-auditbackend
rationale: verify that Linux Audit logging is enabled for the USBGuard daemon
- name: rhcos4-usbguard-allow-hid-and-hub
rationale: We will allow Human Interface Devices and hubs
title: Ensure USBGuard is enabled
Applying usbguard rule will trigger multiple reboots:
$oc get cr
NAME STATE
enable-usbguard-tp-master-package-usbguard-installed Applied
enable-usbguard-tp-master-service-usbguard-enabled MissingDependencies
enable-usbguard-tp-master-usbguard-allow-hid-and-hub MissingDependencies
enable-usbguard-tp-worker-package-usbguard-installed Applied
enable-usbguard-tp-worker-service-usbguard-enabled MissingDependencies
enable-usbguard-tp-worker-usbguard-allow-hid-and-hub MissingDependencies
USBGuard Service has to be installed before it can be enabled, so you would have to wait for the remediation to be applied and MachineConfigPool to become ready and then rerun the scan.
How to undo the mitigation
Once software fix is available for your OpenShift version, upgrade and consider removing the mitigation.
To undo, either unapply the remediation or delete the MachineConfig resource created.