linux-kernel - Re: USB Denial Of Service

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 for Android: free password hash cracker in your pocket

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

Message-ID: <2024061236-diabolic-wisplike-d2b1@gregkh>
Date: Wed, 12 Jun 2024 11:55:17 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Oliver Neukum <oneukum@...e.com>,
	USB mailing list <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: USB Denial Of Service

On Tue, Jun 11, 2024 at 10:35:12AM -0400, Alan Stern wrote:
> Greg, Oliver, or anyone else:
> 
> Questions:
> 
> If a broken or malicious device causes a USB class driver to add a 
> thousand (or more) error messages per second to the kernel log, 
> indefinitely, would that be considered a form of DOS?
> 
> Should the driver be fixed?

Good question.  Right now, by default, we "trust" usb devices to an
extent.  We have been "pushing back" that boundry over time, such that
now we will validate USB descriptors to verify that they actually are
sane before allowing a driver to bind to them, and if there's any bugs
with that, we will fix them.

But we totally trust the data stream from devices, and trust that once
an urb is submitted, they work properly.

If we wish to change that threat model, great, but that will require
those that wish to change that model to DO THE ACTUAL WORK!

I don't want to see fuzzers start to fuzz the data streams of USB
drivers and expect us to fix the bugs.  That's flat out not ok, as this
is something that right now, we do not care about.  If companies do care
about this, they need to do the work as that is NOT how Linux is
currently designed and implemented.

Same goes for other device types.  I get this conversation all the time
(had it last week at a very very very large Linux company.)  It usually
goes something like:

	Them:	We want to claim that we can trust drivers to work
		properly for malicious devices
	Me:	Wonderful, send the patches to do so, fixing up all
		subsystems that rely on them!
	Them:	No, that's something that Linux should already support.
	Me:	Why do you care about this?
	Them:	Because we want to host systems in untrusted situations.
	Me:	So you want to save money by not using a single physical
		host.
	Them:	Yes.
	Me:	Then spend some of that money to do the work to make
		this happen, do not force the community to do it for you.
	Them:	...

> What is an acceptable rate for an unending stream of error messages?  
> Once a second?  Once a minute?

The *_ratelimited() functions should handle this if you want to use
them.

> At what point should the driver give up and stop trying to communicate 
> with the device?

That's tricky, we don't have good answers for that as everyone has a
different idea of how long "flaky" devices should be able to flake out
before coming back.

> (These are not moot questions.  There are indeed drivers, and probably 
> not just in the USB subsystem, subject to this sort of behavior.)

Totally agreed.  But again, the design of Linux right now is that we
implicitly trust the hardware we are running on.  If that design
decision wants to be changed, some people need to do a ton of work to
change it.

Thanks,

greg k-h