Message-ID: <CANP3RGeiQgcJ6zj3OHvoLy=f+spB7Xmv9gKuGoBwajwMFR08Jg@mail.gmail.com>
Date:   Thu, 13 Jul 2023 11:49:31 +0200
From:   Maciej Żenczykowski <maze@...gle.com>
To:     Oliver Neukum <oneukum@...e.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Johannes Berg <johannes@...solutions.net>,
        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>,
        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

I know the NCM protocol a *lot* better than I do RNDIS, but...

RNDIS is just passing around chunks of memory (packets with some
metadata) over a usb channel.
*Any and all* exploits can be fixed - this isn't a complex DMA level
HW problem like pcie or firewire.
The trouble is finding the problems (ie. the places where input
validation is missing or wrong).
Indeed if you can write an exploit, it means you understand the
problem well enough to fix it,
and indeed fixing it is going to be *much* easier than writing the exploit.
(the hard part is finding the problems)

The (rndis host) code could probably be audited - the protocol is not
(afaik) that complex,
nor is the driver all that large.

I no longer have the email reporting the problems (deleted in a mass
inbox zero purge by mistake), but from what I recall
at least a few of them should have been fixable by making types
unsigned instead of signed and the like.
(ie. adding basic checks for whether values are in range)

As for things we can do:

- I think we can outright delete Linux' RNDIS gadget side code - that
should be half the problem.
Why? Because Linux/Mac support better protocols (CDC NCM) and Windows
10+ NCM support exists too.
(though the windows driver is afaik a little bit buggier than I'd like...)
Android devices (phones, etc) that support RNDIS gadget side don't
(AFAIK) use the upstream rndis gadget code anyway,
they use out-of-tree versions with offload support (at least afaik
that's the case for qualcomm chipsets).
Devices without hw reasons (offload) to use RNDIS can just switch to NCM.
Deleting it in Linux 6.~5+ doesn't affect older Linux versions anyway,
so it doesn't affect any older devices...

(Though deleting the code does mean we lose the ability to test linux
host side with linux gadget side...
I guess you can always just use an old kernel (or even just an old
phone) on the gadget side to test that combo...)

- I think we could change the RNDIS host side driver to be default
disabled (or even experimental)
However, be aware people (Linux users wanting to usb tether their
laptops off of most Android phones out there) will complain if we do
this and distros will end up enabling them anyway.

What we should really do is just start finding/fixing the bugs in the
rndis_host side.
It *cannot* be that hard.

If someone re-forwards me the kernel-security report, I promise to
send back at least a few fixes...

Powered by blists - more mailing lists