linux-kernel - Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer Dereference&Use-After-Free Vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240806030619.GB1008477@mit.edu>
Date: Mon, 5 Aug 2024 23:06:19 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: LidongLI <wirelessdonghack@...il.com>
Cc: gregkh@...uxfoundation.org, kvalo@...nel.org, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org, linux-wireless@...r.kernel.org,
        mark.esler@...onical.com, stf_xl@...pl
Subject: Re: Ubuntu RT2X00 WIFI USB Driver Kernel NULL pointer
 Dereference&Use-After-Free Vulnerability

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