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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ