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: <20240806124519.GA1174689@mit.edu>
Date: Tue, 6 Aug 2024 08:45: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

I was taking a closer look at your reproducer, and there's even a
bigger problem.  Your reproducer runs the moral equivalent of this:

   import usb.core

   dev = usb.core.find(idVendor=0xb58e, idProduct=0x0005)
   dev.reset()

(I've changed the USB vendor/product id's to my Blue Yeti microphone,
so that it was a valid USB device; but that doesn't matter for the
purposes of this demonstration.)

The reset method requires root privileges!

usb.core.USBError: [Errno 13] Access denied (insufficient permissions)

So how does this actually show up in a real life exploit?  The
attacker won't have root privileges, or it's already game over.  If
this is an embedded device, the USB device will be soldered onto the
PC board, so you're not going to be able to plug and unplug it a
hundreds time, with a tenth of a second between plug/unplug cycles
(good luck having a human do that, BTW).

And if you do have physical access, and it's not soldered in -- in
most situations, if you have phyysical access to the device, it's also
likely game over.  For example, you could plug into the debug headers,
and just flash a new firmware onto the embedded device, and again,
game over.

Again, this may very well be a bug.  But not all bugs are real life
security exploits.  This is especially true for syzbot-generated
noise, which runs its "attack scripts" as root.  The excuse given for
this is that it finds real kernel bugs, which may be true (although
others are still syzbot-generated noise); however, not all kernel bugs
are CVE-worthy.

Best regards,

						- Ted