3 ms·

How does the exploit work? Can it be executed remotely, even via prepared websites or is access to the Hardware required?

hkwerf 2y ago
That's what I'm wondering too. This is in uvcvideo, processing data from USB-connected cameras. So, maybe you can exploit it by connecting a camera to the USB port? That would be bad enough. But this code only seems to be called if a video stream is active. So things like unlocking a locked phone seems improbable to be possible.
- KwanEsq 2y ago
  Well that depends, the camera app is generally accessible on locked phones, so the question is, can the camera app make use of USB-connected cameras, and if so is there any restriction on accessing such cameras in locked mode (like there is a restriction on accessing past photos).
  - hkwerf 2y ago
    I'm not sure, most vendor camera apps were pretty much tied to the particular camera on the phone, on the phones I've had. For UVC, I usually needed to use another camera app. You could try to initiate a video call with the locked device, though.
shakna 2y ago
It's an out-of-bounds write, caused by injecting UVC_VS_UNDEFINED frames into the video file, as they weren't size-handled correctly. Which means, unfortunately, that playing a video file with that particular driver is all that would be needed. The constructed video file would need a second exploit to jump out of the virtual memory of the driver and into the kernel, but that has happened before [1]. It's a high risk. Or it could just be used to crash every device that sees the video in a DoS attack. However, the devices that use those drivers tend not to be end-user devices (webcams, smart TVs, TV tuners, recorders, etc.) They would be used as an entrypoint, before moving laterally into a network. So, standard IoT type breach. [0] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=faff5bbb2762c44ec7426037b3000e77a11d6773 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... [1] https://github.com/0xdevil/CVE-2021-42008 https://github.com/0xdevil/CVE-2021-42008
- ajross 2y ago
  This is not correct. The UVC code isn't involved in the playback path. It's the USB class driver for video capture devices. You have to plug a malicious webcam into the phone.
ajross 2y ago
It's in the USB UVC video class driver, so no. You need to plug a malicious piece of hardware into the device, presumably.

hkwerf 2y ago

That's what I'm wondering too. This is in uvcvideo, processing data from USB-connected cameras. So, maybe you can exploit it by connecting a camera to the USB port? That would be bad enough. But this code only seems to be called if a video stream is active. So things like unlocking a locked phone seems improbable to be possible.

KwanEsq 2y ago
Well that depends, the camera app is generally accessible on locked phones, so the question is, can the camera app make use of USB-connected cameras, and if so is there any restriction on accessing such cameras in locked mode (like there is a restriction on accessing past photos).
- hkwerf 2y ago
  I'm not sure, most vendor camera apps were pretty much tied to the particular camera on the phone, on the phones I've had. For UVC, I usually needed to use another camera app. You could try to initiate a video call with the locked device, though.

shakna 2y ago

It's an out-of-bounds write, caused by injecting UVC_VS_UNDEFINED frames into the video file, as they weren't size-handled correctly. Which means, unfortunately, that playing a video file with that particular driver is all that would be needed. The constructed video file would need a second exploit to jump out of the virtual memory of the driver and into the kernel, but that has happened before [1]. It's a high risk. Or it could just be used to crash every device that sees the video in a DoS attack. However, the devices that use those drivers tend not to be end-user devices (webcams, smart TVs, TV tuners, recorders, etc.) They would be used as an entrypoint, before moving laterally into a network. So, standard IoT type breach. [0] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=faff5bbb2762c44ec7426037b3000e77a11d6773 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... [1] https://github.com/0xdevil/CVE-2021-42008 https://github.com/0xdevil/CVE-2021-42008

ajross 2y ago
This is not correct. The UVC code isn't involved in the playback path. It's the USB class driver for video capture devices. You have to plug a malicious webcam into the phone.

ajross 2y ago

It's in the USB UVC video class driver, so no. You need to plug a malicious piece of hardware into the device, presumably.