SLE15-SP4 supports supports RNDIS on wired host mode (gadget mode is !optional) and includes the drivers for gadget and wired and wireless host mode. SP3 is identical.

Older kernels do not support gadget mode, but support for wired host mode goes back all the way to v3.0

Reassigning to Oliver at best.

Greg has a kernel tree with this commit. It is from November. It looks to me like this is going nowhere upstream, yet they are not disclosing details on the vulnerability.

commit ce3480c31462229e77b324c746b69e842a6d8a1b (HEAD -> rndis-removal, origin/rndis-removal)
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Nov 23 13:40:35 2022 +0100

    USB: disable all RNDIS protocol drivers
    
    The Microsoft RNDIS protocol is, as designed, insecure and vulnerable on
    any system that uses it with untrusted hosts or devices.  Because the
    protocol is impossible to make secure, just disable all rndis drivers to
    prevent anyone from using them again.
    
    Windows only needed this for XP and newer systems, Windows systems older
    than that can use the normal USB class protocols instead, which do not
    have these problems.
    
    Android has had this disabled for many years so there should not be any
    real systems that still need this.
    
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: Kalle Valo <kvalo@kernel.org>
    Cc: Oleksij Rempel <linux@rempel-privat.de>
    Cc: "Maciej Żenczykowski" <maze@google.com>
    Cc: Neil Armstrong <neil.armstrong@linaro.org>
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: Andrzej Pietrasiewicz <andrzejtp2010@gmail.com>
    Cc: Jacopo Mondi <jacopo@jmondi.org>
    Cc: "Łukasz Stelmach" <l.stelmach@samsung.com>
    Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Cc: linux-usb@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-wireless@vger.kernel.org
    Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
    Reported-by: Joseph Tartaro <joseph.tartaro@ioactive.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

CRD: unknown

Created attachment 868917 [details]
patch for suse-module-tools

patch for s-m-t as requested in jsc#PED-2788

Please double check. I wasn't sure if I can push this to github, so I didn't.

How to proceed further? Is comment 19 ok to apply publicly?

I think we can consider it public and apply patches.

I've submitted s-m-t with the blacklist entries to Factory and SLE15-SP2 and later. Let me know if you need more.

(In reply to Oliver Neukum from comment #16)
> Greg has a kernel tree with this commit. It is from November. It looks to me
> like this is going nowhere upstream, yet they are not disclosing details on
> the vulnerability.
> 
> commit ce3480c31462229e77b324c746b69e842a6d8a1b (HEAD -> rndis-removal,
> origin/rndis-removal)
> Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Date:   Wed Nov 23 13:40:35 2022 +0100
> 
>     USB: disable all RNDIS protocol drivers
>     
>     The Microsoft RNDIS protocol is, as designed, insecure and vulnerable on
>     any system that uses it with untrusted hosts or devices.  Because the
>     protocol is impossible to make secure, just disable all rndis drivers to
>     prevent anyone from using them again.
>     
>     Windows only needed this for XP and newer systems, Windows systems older
>     than that can use the normal USB class protocols instead, which do not
>     have these problems.
>     
>     Android has had this disabled for many years so there should not be any
>     real systems that still need this.
>     
>     Cc: "David S. Miller" <davem@davemloft.net>
>     Cc: Eric Dumazet <edumazet@google.com>
>     Cc: Jakub Kicinski <kuba@kernel.org>
>     Cc: Paolo Abeni <pabeni@redhat.com>
>     Cc: Kalle Valo <kvalo@kernel.org>
>     Cc: Oleksij Rempel <linux@rempel-privat.de>
>     Cc: "Maciej Żenczykowski" <maze@google.com>
>     Cc: Neil Armstrong <neil.armstrong@linaro.org>
>     Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
>     Cc: Andrzej Pietrasiewicz <andrzejtp2010@gmail.com>
>     Cc: Jacopo Mondi <jacopo@jmondi.org>
>     Cc: "Łukasz Stelmach" <l.stelmach@samsung.com>
>     Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>     Cc: linux-usb@vger.kernel.org
>     Cc: netdev@vger.kernel.org
>     Cc: linux-kernel@vger.kernel.org
>     Cc: linux-wireless@vger.kernel.org
>     Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
>     Reported-by: Joseph Tartaro <joseph.tartaro@ioactive.com>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Hi all
it seems that " Android has had this disabled for many years so there should not be any real systems that still need this." is not fully true.
There are several smartphone that now are unable to use the USB tethering. Mine is a Motorola Edge 20, my friend has a recent Samsung. Please check this functionality with your smartphone as well.
There is already a bug for tethering https://bugzilla.suse.com/show_bug.cgi?id=1216155

Furthermore, probably also printers connected via USB now have a problem: https://bugzilla.opensuse.org/show_bug.cgi?id=1215478

So please reconsider the decision to take off the RNDIS driver: switch off the this component without knowing what causes the issue seems too drastic decision. If we always apply this criteria, we would switch off all the computers.

Thank you!

*** Bug 1216155 has been marked as a duplicate of this bug. ***

This assumption about Android devices not requiring RNDIS any longer is based on an invalid conclusion:

"Android has had this disabled for many years so there should not be any real systems that still need this."

Even though Google / Android may have wanted to get rid of it, Microsoft have been slow to change Windows... As a consequence, at least some phone manufacturers apparently have been following suit in doing nothing to stay compatible with Windows. Windows 10 apparently still uses RNDIS, and the transition appears to be happening somewhere between Windows 10 and Windows 11:

https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/supported-usb-classes

At this stage, there are definitely still fairly recent Android phones that are relying on RNDIS. My Samsung Galaxy Xcover Pro purchased new last year is one of them.

May I suggest taking a more measured approach by keeping RNDIS and adding NCM, making NCM the default, and providing an explicit warning about the risk of using RNDIS for those who still need it?

This is an autogenerated message for OBS integration:
This bug (1205767) was mentioned in
https://build.opensuse.org/request/show/1118229 Factory / suse-module-tools

SUSE-SU-2023:4097-1: An update that solves one vulnerability, contains one feature and has one security fix can now be installed.

Category: security (important)
Bug References: 1205767, 1210335
CVE References: CVE-2023-1829
Jira References: PED-5731
Sources used:
SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2 (src): suse-module-tools-15.2.18-150200.4.15.1
SUSE Linux Enterprise Server for SAP Applications 15 SP2 (src): suse-module-tools-15.2.18-150200.4.15.1
SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2 (src): suse-module-tools-15.2.18-150200.4.15.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

SUSE-SU-2023:4136-1: An update that solves two vulnerabilities and contains one feature can now be installed.

Category: security (important)
Bug References: 1205767, 1210335
CVE References: CVE-2023-1829, CVE-2023-23559
Jira References: PED-5731
Sources used:
SUSE Linux Enterprise Micro 5.5 (src): suse-module-tools-15.5.3-150500.3.6.1
Basesystem Module 15-SP5 (src): suse-module-tools-15.5.3-150500.3.6.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

SUSE-SU-2023:4135-1: An update that solves two vulnerabilities and contains one feature can now be installed.

Category: security (important)
Bug References: 1205767, 1210335
CVE References: CVE-2023-1829, CVE-2023-23559
Jira References: PED-5731
Sources used:
SUSE Linux Enterprise Micro for Rancher 5.3 (src): suse-module-tools-15.4.18-150400.3.14.1
SUSE Linux Enterprise Micro 5.3 (src): suse-module-tools-15.4.18-150400.3.14.1
SUSE Linux Enterprise Micro for Rancher 5.4 (src): suse-module-tools-15.4.18-150400.3.14.1
SUSE Linux Enterprise Micro 5.4 (src): suse-module-tools-15.4.18-150400.3.14.1
Basesystem Module 15-SP4 (src): suse-module-tools-15.4.18-150400.3.14.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

What does previous message mean?

SUSE-SU-2023:4160-1: An update that solves two vulnerabilities and contains one feature can now be installed.

Category: security (important)
Bug References: 1205767, 1210335
CVE References: CVE-2023-1829, CVE-2023-23559
Jira References: PED-5731
Sources used:
SUSE Linux Enterprise Server for SAP Applications 15 SP1 (src): suse-module-tools-15.1.25-150100.3.25.1
SUSE CaaS Platform 4.0 (src): suse-module-tools-15.1.25-150100.3.25.1
SUSE Linux Enterprise High Performance Computing 15 SP1 LTSS 15-SP1 (src): suse-module-tools-15.1.25-150100.3.25.1
SUSE Linux Enterprise Server 15 SP1 LTSS 15-SP1 (src): suse-module-tools-15.1.25-150100.3.25.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

SUSE-SU-2023:4159-1: An update that solves two vulnerabilities, contains one feature and has one security fix can now be installed.

Category: security (important)
Bug References: 1187196, 1205767, 1210335
CVE References: CVE-2023-1829, CVE-2023-23559
Jira References: PED-5731
Sources used:
SUSE Linux Enterprise High Performance Computing 12 SP5 (src): suse-module-tools-12.13-3.11.1
SUSE Linux Enterprise Server 12 SP5 (src): suse-module-tools-12.13-3.11.1
SUSE Linux Enterprise Server for SAP Applications 12 SP5 (src): suse-module-tools-12.13-3.11.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

SUSE-SU-2023:4158-1: An update that solves two vulnerabilities, contains one feature and has one security fix can now be installed.

Category: security (important)
Bug References: 1205767, 1207853, 1210335
CVE References: CVE-2023-1829, CVE-2023-23559
Jira References: PED-5731
Sources used:
SUSE Linux Enterprise High Performance Computing ESPOS 15 SP3 (src): suse-module-tools-15.3.17-150300.3.22.1
SUSE Linux Enterprise High Performance Computing LTSS 15 SP3 (src): suse-module-tools-15.3.17-150300.3.22.1
SUSE Linux Enterprise Server 15 SP3 LTSS 15-SP3 (src): suse-module-tools-15.3.17-150300.3.22.1
SUSE Linux Enterprise Server for SAP Applications 15 SP3 (src): suse-module-tools-15.3.17-150300.3.22.1
SUSE Manager Proxy 4.2 (src): suse-module-tools-15.3.17-150300.3.22.1
SUSE Manager Retail Branch Server 4.2 (src): suse-module-tools-15.3.17-150300.3.22.1
SUSE Manager Server 4.2 (src): suse-module-tools-15.3.17-150300.3.22.1
SUSE Enterprise Storage 7.1 (src): suse-module-tools-15.3.17-150300.3.22.1
SUSE Linux Enterprise Micro 5.1 (src): suse-module-tools-15.3.17-150300.3.22.1
SUSE Linux Enterprise Micro 5.2 (src): suse-module-tools-15.3.17-150300.3.22.1
SUSE Linux Enterprise Micro for Rancher 5.2 (src): suse-module-tools-15.3.17-150300.3.22.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

Hi all
any update on this item?

You can see in comment 39 that the suse-module-tools updates with the blacklist entries have been published.

(In reply to Martin Wilck from comment #41)
> You can see in comment 39 that the suse-module-tools updates with the
> blacklist entries have been published.

Hi
I'm not sure about meaning of suse-module-tools, but in Tumbleweed USB tethering is still not working

FYI
my end-user experience
(I know basically nothing in this area)
with openSUSE Leap 15.5
with Standard Gnome and Network Manager:

I work in homeoffice.

I want network connection via USB tethering
to my smartphone's mobile network Internet connection
to have a backup for my ISP's router box which would
otherwise be a single point of total failure
e.g. when its DSL connection does not work
(which happened just today morning for some hours).

USB tethering on Leap did not at all work for me
because the kernel module 'rndis_host' was not loaded
so the kernel does not make a 'usb0' network link
and then nothing else happens
(in this case there is zero information in the desktop
 GUI stuff - it just leaves its user in emptiness).

After manual "modprobe rndis_host"
(that also loads cdc_ether and usbnet)
USB tethering "just works".

A proposal:
When automatic loading of 'rndis_host' is not possible
for security reasons (which I appreciate), then the user
should be at least informed by the desktop GUI tools.

Side notes:

All I could find in the Internet was that
USB tethering "just works" (also for openSUSE users).
Of course once you now that 'rndis_host' is the
"magic word" one finds issue reports on the Internet.

https://wiki.gentoo.org/wiki/Android_USB_tethering
reads (excerpt)
-------------------------------------------------------
Important
RNDIS linux module is being deprecated and
will be removed from the Linux Kernel
in favor Network Control Model (NCM),
but it is used by majority of devices nowadays (2023)
and up to now the only way to configure working
USB tethering for old Android devices.
For more recent devices (Android 14 era) try to
use "Network Control Model (NCM) support" module first. 
-------------------------------------------------------
so it seems currently and also for the next years
RNDIS is the only way to configure working
USB tethering for many users with Android devices.

(In reply to Ferdinando Vivacqua from comment #42)

> I'm not sure about meaning of suse-module-tools, but in Tumbleweed USB
> tethering is still not working

Johannes basically said it already. To make USB tethering work either you need to load the "rndis_host" module manually (modprobe rndis_host), or you need to override the blacklist entry:

ln -s /dev/null /etc/modprobe.d/50-blacklist-rndis.conf

If you use USB tethering on a regular basis, this is what I would recommend.

Manual action on your part is necessary. This way you acknowledge that you deliberately load the rndis_host driver although you've been warned that the protocol may be insecure. IOW, you have confirmed that the alleged security risks don't apply to your setup, or that you consider them so low that you're willing to take the risk.

I fully agree that this needs better documentation on our part.

(In reply to Martin Wilck from comment #44)
> (In reply to Ferdinando Vivacqua from comment #42)
> 
> > I'm not sure about meaning of suse-module-tools, but in Tumbleweed USB
> > tethering is still not working
> 
> Johannes basically said it already. To make USB tethering work either you
> need to load the "rndis_host" module manually (modprobe rndis_host), or you
> need to override the blacklist entry:
> 
> ln -s /dev/null /etc/modprobe.d/50-blacklist-rndis.conf
> 
> If you use USB tethering on a regular basis, this is what I would recommend.
> 
> Manual action on your part is necessary. This way you acknowledge that you
> deliberately load the rndis_host driver although you've been warned that the
> protocol may be insecure. IOW, you have confirmed that the alleged security
> risks don't apply to your setup, or that you consider them so low that
> you're willing to take the risk.
> 
> I fully agree that this needs better documentation on our part.

Ok, thank you for your feeback.

Regarding "this needs better documentation":

I would most of all like to understand
what the security issue actually is
to be able to make a sufficiently informed
and reasonable decision.

The above comment #16 which is basically same as
https://lore.kernel.org/lkml/20221123124620.1387499-1-gregkh@linuxfoundation.org/
only states (excerpt):
-----------------------------------------------------------
The Microsoft RNDIS protocol is, as designed,
insecure and vulnerable on any system
that uses it with untrusted hosts or devices
-----------------------------------------------------------

There is no information what "untrusted hosts or devices"
actually means in practice.
Up to now I could not find actually more explanatory
information on the Internet.
All I could find speaks about "trusted devices"
but does not explain what that means in practice, e.g.
https://www.zdnet.com/home-and-office/networking/linux-tries-to-dump-windows-notoriously-insecure-rndis-protocol/
which reads (excerpts):
-----------------------------------------------------------
The protocol was never designed to be used with
untrusted devices.
It was created, and we implemented support for it, when
we trusted USB devices that we plugged into our systems,
AND we trusted the systems we plugged our USB devices into.

Today, with untrusted hosts and devices,
it's time just to retire this protocol.

... systems that use this will always have to trust
that the device plugged into them is "trusted."
...
There are reasons why security-conscious businesses
don't allow any USB-connected devices on-premises,
and this is one of them. 
-----------------------------------------------------------

In my case I own the laptop, USB cable, and smartphone.
I am the only user of laptop, USB cable, and smartphone.
I trust the operating system on the laptop (Leap 15.5)
and I trust the USB cable (google for "usb o.mg cable")
but can one trust an Andriod smartphone in general
and in particular when the smartphone had been
already "used as usual" for some longer time?


Then comment #44 reads (excerpt):
-----------------------------------------------------------
Manual action on your part is necessary.
This way you acknowledge that you deliberately load
the rndis_host driver although you've been warned
that the protocol may be insecure.
IOW, you have confirmed that the alleged security risks
don't apply to your setup, or that you consider them
so low that you're willing to take the risk.
-----------------------------------------------------------
How should I as an end-user
(I am not at all an expert in this area)
make a sufficiently informed and reasonable decision
whether or not those "alleged security risks"
(what exactly are those risks?)
apply or are sufficiently low in my case?


Ony a blind guess from what I suspect currently:

Is the security risk perhaps basically about that
when 'rndis_host' gets automatically loaded,
then a hacker with access to USB ports on a Linux system
could plug in his specially crafted "hacking smartphone"
and the kernel on the Linux system would automatically
provide the hacker a 'usb0' network interface?

(In reply to Johannes Meixner from comment #46)

> In my case I own the laptop, USB cable, and smartphone.
> I am the only user of laptop, USB cable, and smartphone.
> I trust the operating system on the laptop (Leap 15.5)
> and I trust the USB cable (google for "usb o.mg cable")
> but can one trust an Andriod smartphone in general
> and in particular when the smartphone had been
> already "used as usual" for some longer time?

I can't give expert advice on this. It sounds reasonably safe. But OTOH, your smartphone might have been hijacked by an attacker long ago without you even noticing.

> Then comment #44 reads (excerpt):
> -----------------------------------------------------------
> Manual action on your part is necessary.
> This way you acknowledge that you deliberately load
> the rndis_host driver although you've been warned
> that the protocol may be insecure.
> IOW, you have confirmed that the alleged security risks
> don't apply to your setup, or that you consider them
> so low that you're willing to take the risk.
> -----------------------------------------------------------
> How should I as an end-user
> (I am not at all an expert in this area)
> make a sufficiently informed and reasonable decision
> whether or not those "alleged security risks"
> (what exactly are those risks?)
> apply or are sufficiently low in my case?

Well, you can't. But still, you have to :-/

In theory, you need to try to understand the attack scenario in detail and evaluate whether or not it applies to your use case. In practice, you can try but unless you're a security expert, you can't reach a reliable judgement.
You will have to make a partially-informed decision.

We, SUSE, as the distributor of the package, are perhaps more technically competent to judge the risk on the theoretical level, but we know nothing about your use case. For example you may or may not use your smart phone in public networks, or have given the PIN to your child, etc. Therefore SUSE can basically just choose the safe option as default. By auto-loading the module, SUSE might be held legally responsible for the potential damage.

Even with much improved documentation, SUSE can't take the burden to make the final decision from the end user.

> Ony a blind guess from what I suspect currently:
> 
> Is the security risk perhaps basically about that
> when 'rndis_host' gets automatically loaded,
> then a hacker with access to USB ports on a Linux system
> could plug in his specially crafted "hacking smartphone"
> and the kernel on the Linux system would automatically
> provide the hacker a 'usb0' network interface?

That's part of the picture but I doubt it's all. If there was nothing more, I wonder how the "Network Control Model" (comment 43) would fix the issue. Comment 1 suggests that the RNDIS protocol has weaknesses that would allow the compromised smart phone to do more harm in this situation than it could with a secure protocol. 

Just guessing wildly. Perhaps someone else can clarify.

SUSE-SU-2024:0155-1: An update that solves two vulnerabilities, contains one feature and has one security fix can now be installed.

Category: security (important)
Bug References: 1205767, 1210335, 1217775
CVE References: CVE-2023-1829, CVE-2023-23559
Jira References: PED-5731
Sources used:
SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2 (src): suse-module-tools-15.2.19-150200.4.18.1
SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2 (src): suse-module-tools-15.2.19-150200.4.18.1
SUSE Linux Enterprise Server for SAP Applications 15 SP2 (src): suse-module-tools-15.2.19-150200.4.18.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.