On Tue, Aug 06, 2024 at 09:59:04AM +0800, LidongLI wrote: > > Yes, as you mentioned, it requires users to create their own udev > rules, which is not common among Ubuntu personal users. However, in > some non-personal user scenarios, they must pre-add udev rules to > meet their needs. A simple example: in some Ubuntu embedded Linux > scenarios, we found that when starting a wireless hotspot, > developers must configure udev rules to ensure a stable connection, > enable auto-loading of drivers, or auto-run or write USB-based > auto-configuration scripts. Yes, but when the user is setting up their own udev rules, they are editing them as root (e.g, "sudo nano /etc/udev/rules.d/"). But in your exploit scenario, the *attacker* needs to be able to insert a specific udev rule to allow the attack to succeed. So that means that the attacker needs to be able to manipulate the user to insert a udev rule which allows the attacker to acarry out the attack, or the user has left the udev rule file in such a way that it is writeable by the attacker. But in that case, the attacker can just edit the udev rule to arrange to run some script as root, ad it's already game over. Your argument is roughly the same as "sudo is a vulerability because the attacker could run (or trick the user to run) the command 'sudo chmod 4755 /bin/bash'. Well yes, if the attacker can arrange to run a particular command as root, it's game over. But that's not a security bug, but rather a bug in the gullible user who has root access. Similarly, if the user has a insecure configuration --- say, suppose the user has run the command "sudo chmod 4755 /bin/bash", it does not follow that this is a reason to request a CVE for /bin/bash. It's not really a security bug in /bin/bash, but a bug in how /bin/bash was confiured. Cheers, - Ted
