On Mon, Aug 05, 2024 at 04:33:39PM +0800, LidongLI wrote:
>
> Dear Greg,
>
> Thank you for your response and for considering the details I've provided so far. I would like to offer further clarification on the vulnerability and why it warrants assigning a CVE.
>
> ### Detailed Description of Vulnerability
>
> 1. **Root Cause and Exploitability**:
> - The vulnerability in question can be triggered by sending specific data packets to a device driver, causing a Null Pointer Dereference in the kernel. This results in a complete system crash and reboot.
Are you sure it's the sending random data and not the reset that is
causing this? You also are attempting to send confused data while the
driver is binding, so of course it is going to get confused, how could
it not?
> - While initially it appears to require root privileges, altering the Udev rules allows for exploiting this vulnerability from a non-root user space, significantly lowering the barrier for potential exploitation.
Exactly what udev rule changes are required? And as that requires root
permission, that is not really that big of an issue, right?
> 2. **Impact on Systems**:
> - The root cause is a race condition between the userspace resetting the device and the kernel driver initializing it. This is not an edge case but a common scenario that could occur in systems where devices are frequently reset or reinitialized.
> - By manipulating Udev rules, an attacker can create a persistent and repeatable method to exploit the vulnerability, leading to Denial of Service (DoS) conditions. This can be particularly disruptive in production environments, impacting servers, IoT devices, and embedded systems relying on Ubuntu.
If you can change udev rules, you own the machine, this is not a kernel
issue. Again, there is a reason why normal users can't do this.
> 3. **Practical Implications**:
> - The fact that this can be achieved through Udev rules modification is significant because it demonstrates a path to escalate privileges and attack vectors that can be exploited in real-world scenarios.
> - Systems that are exposed to user-space applications needing device resets or control operations could be particularly vulnerable, especially in multi-user environments.
>
> ### Experimental Evidence
> ### Setting Up Udev Rules: Granting Permissions to Your USB Device Without Using sudo
>
> To grant permissions to your USB device without using `sudo`, you need to create a udev rules file. Follow these steps:
>
> #### Create the Udev Rules File:
>
> 1. Open a terminal and create the udev rules file with the following command:
>
>
> sudo nano /etc/udev/rules.d/99-usb.rules
>
>
> 2. Add the rule: In the file, add the following content. Replace `YOUR_VENDOR_ID` and `YOUR_PRODUCT_ID` with your device's vendor ID and product ID.
>
>
> SUBSYSTEM=="usb", ATTR{idVendor}=="148f", ATTR{idProduct}=="3070", MODE="0666"
So you are allowing any user to read/write to the device at the same
time the driver is bound to it, but again, you had to be root to allow
this to happen.
So unless a normal user can do this, with the default permissions, this
is just going to be a normal "fix up the usb driver to allow confused
data to not confuse it" which is a normal thing. USB drivers were never
originally designed to allow for malicious devices. We have slowly
changed this over time to allow for semi-malicious USB configuration
data to be handled properly, but we have not said "USB devices are not
fully trusted" yet. If we want to do that, we need to do a lot of work
as that is not how Linux (or really any operating system) is designed at
the moment.
Again, we will be glad to fix up the individual bugs here as found, but
it's not a major issue as it's just something that someone with root
permissions can do to a machine, along with thousands of worse things :)
thanks,
greg k-h
