netdev - Re: [PATCH] USB: disable all RNDIS protocol drivers

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: <de77578f-a783-a241-3ef5-e74f49029bb5@suse.com>
Date: Thu, 13 Jul 2023 10:33:28 +0200
From: Oliver Neukum <oneukum@...e.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Johannes Berg <johannes@...solutions.net>
Cc: Oliver Neukum <oneukum@...e.com>, Enrico Mioso <mrkiko.rs@...il.com>,
 Jan Engelhardt <jengelh@...i.de>, linux-kernel@...r.kernel.org,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Kalle Valo <kvalo@...nel.org>, Oleksij Rempel <linux@...pel-privat.de>,
 Maciej Żenczykowski <maze@...gle.com>,
 Neil Armstrong <neil.armstrong@...aro.org>,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Andrzej Pietrasiewicz <andrzejtp2010@...il.com>,
 Jacopo Mondi <jacopo@...ndi.org>, Łukasz Stelmach
 <l.stelmach@...sung.com>,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>,
 linux-usb@...r.kernel.org, netdev@...r.kernel.org,
 linux-wireless@...r.kernel.org, Ilja Van Sprundel
 <ivansprundel@...ctive.com>, Joseph Tartaro <joseph.tartaro@...ctive.com>
Subject: Re: [PATCH] USB: disable all RNDIS protocol drivers

On 13.07.23 07:34, Greg Kroah-Hartman wrote:
> On Thu, Jul 13, 2023 at 02:28:26AM +0200, Johannes Berg wrote:
>> On Wed, 2023-07-12 at 18:39 +0200, Greg Kroah-Hartman wrote:

Hi,

>> All we said is that your statement of "RNDIS is fundamentally unfixable"
>> doesn't make a lot of sense. If this were the case, all USB drivers
>> would have to "trust the other side" as well, right?
> 
> No, well, yes.  See the zillion patches we have had to apply to the
> kernel over the years when someone decided that "usb devices are not to
> be trusted" that syzbot has helped find :)

Well, there are protocols that are in a sense unfixable. Like,
hypothetical example, you allow the execution of postscript code.
Hence it is kind of important to keep that distinction.

Yes, our attitude here is inconsistent. With the advent of Thunderbolt
we should have gone through all PCI drivers and audited them for things
malicious devices can do.
However, we can wait for Pandora for the purpose of this discussion.

> It's not a DMA issue here, it's a "the protocol allows for buffer
> overflows and does not seem to be able to be verified to prevent this"
> from what I remember (it's been a year since I looked at this last,
> details are hazy.)  At the time, I didn't see a way that it could be
> fixed, hence this patch.

That makes sort of sense, but still leaves us with the option of verifying
each memcopy for being within allowed buffers.

Now, by no means let me stop you from getting into your supervillain outfit
and write exploits. But just telling us the rest of the issues would do, though
not as well.

	Regards
		Oliver