Linux Preparing To Disable Drivers For Microsoft's RNDIS Protocol (phoronix.com) 51
Phoronix reports:
With the next Linux kernel cycle we could see upstream disable their driver support for Microsoft's Remote Network Driver Interface Specification (RNDIS) protocol due to security concerns.
RNDIS is the proprietary protocol used atop USB for virtual Ethernet functionality. The support for RNDIS outside of Microsoft Windows has been mixed. RNDIS isn't widely used today in cross-platform environments and due to security concerns the upstream Linux kernel is looking to move the RNDIS kernel drivers behind the "BROKEN" Kconfig option so they effectively become disabled in future kernel builds.
Ultimately once marked as "BROKEN" for a while, the drivers will likely be eventually removed from the upstream source tree.
Greg Kroah-Hartman wrote in a commit: "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."
RNDIS is the proprietary protocol used atop USB for virtual Ethernet functionality. The support for RNDIS outside of Microsoft Windows has been mixed. RNDIS isn't widely used today in cross-platform environments and due to security concerns the upstream Linux kernel is looking to move the RNDIS kernel drivers behind the "BROKEN" Kconfig option so they effectively become disabled in future kernel builds.
Ultimately once marked as "BROKEN" for a while, the drivers will likely be eventually removed from the upstream source tree.
Greg Kroah-Hartman wrote in a commit: "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."
Wait a sec (Score:3, Interesting)
Re:Wait a sec (Score:4, Informative)
Switch to CDC-ECM [segger.com].
Re: (Score:3, Insightful)
Then yes, your workflow will break, and you will have only yourself to blame for using Microsoft's less secure implementation. Enjoy!
Re: (Score:2, Interesting)
If it's airgapped, why bother upgrading to a Linux kernel that has your beloved RNDIS feature removed?
Re: Wait a sec (Score:1)
Re: (Score:2)
Because of new functionality they may want to consider? Does Apple USB to Ethernet dongles use this same insecure protocol?
No. Apple has never supported RNDIS, although a third-party kernel extension, HoRNDIS (pronounced horrendous), does exist for older versions of macOS.
AFAIK, Apple supports CDC-NCM and CDC-ECM [reddit.com]. Its tethering is based on NCM. Recent versions of Windows should also support NCM. So if you want a single standard that is broadly supported, NCM is probably the best choice.
Re: (Score:2)
Because it's bloody built into firmware for those gizmo devices
"Insecure"?!
I physically control both ends of the USB cable!
Re: (Score:1)
I physically control both ends of the USB cable!
That doesn't mean anything to the security Nazis. We're all IBM customers^Wtenants now. Everything old is new again.
Re: (Score:2)
insecure and vulnerable on any system that uses it with untrusted hosts or devices
That essentially describes every protocol ever. I mean, I'm no fan of MS, but it seems the only reason this is being disabled is because it's coming from MS. If you apply this to everything else you need to disable USB, ethernet, PCIe, SATA, SPI, I2C, ...
Re: (Score:3)
Yes. But your not the sole user on the planet.
And the vast vast majority of machines on the internet are, well, on the internet , and *all* of them are at risk due to the unfixable security flaws of the protocol.
It has to die. And you'll have to figure out how to adjust.
Or just dont upgrade.
Re: (Score:2)
*all* of them are at risk due to the unfixable security flaws of the protocol.
Please list the flaws.
Re: (Score:1)
Why are you so patronizing?
Because they know an answer, which may or may not apply to the situation, but must be stated in a way that affirms said answer.
It happens a lot around this place. Come up with something that the "new order" cannot fathom a need for, and you'll be hit with it. If you continue down this line, you'll be chastised for it. Then, ultimately, you'll be told to install a protocol converter to break whatever it is that is officially done. Because "official" is law.
Re: (Score:2)
There is a working free solution which is already in place and which suits the use case. The code is already available and present and there is probably even already a precompiled module, so the amount of effort involved is extremely low. Expecting mainline Linux to preserve this redundant implementation that nobody should really be using any more anyway is unrealistic. If there is any substantial demand then someone can maintain it out of kernel. It's in the ethernet gadget module anyway, or was last I loo
Re: (Score:2)
Hm. It seems like TFA could have mentioned that.
Re: (Score:2)
Yeah, or probably I could've. The first thing I did when I read this story was to google for alternatives to RNDIS. And lo.
Re: (Score:2)
Why are you so patronizing?
drinkypoo was asked a question, suggested a solution, and got a terse "no" back in response. He then (paraphrased) said, "fine, do it your way".
Everything he said is true; how is that being patronizing?
Re: (Score:2)
Not quite, it is more like removing telnet from the default apps and requiring you to install said package manually. And distro not updating that package anymore. You can most likely use 3rd party repos, or in this case, compile your own kernel with said drivers enabled. And as long as you don't change the hardware you are using, those broken drivers should keep working for years.
Re: (Score:3)
Then yes, your workflow will break, and you will have only yourself to blame for using Microsoft's implementation
ftfy
Quite frankly, relying on anything MS is like relying on anything Google. Eventually it will be pulled out under you and you'll be left flailing.
Re: (Score:1)
Comment removed (Score:4, Insightful)
Re: (Score:2)
we shouldn't have to throw out working hardware because someone somewhere decided that there's a way to exploit in a set of circumstances that pretty much assumes the owner of the computer and network has no control over who is using it.
As much as I agree with that sentiment, the current trend in the IT industry is to mandat.....err assume that only the vendor has control over anything and that the "owner" is a complete idiot that should have never been allowed around the controls in the first place. Of course they're going to make this change. They would be labeled "irresponsible" by the voices that matter if they didn't. The fact that it's convenient for multiple special interests is also purely a coincidence.
Re: (Score:3)
Quite frankly, relying on anything MS is like relying on anything Google. Eventually it will be pulled out under you and you'll be left flailing.
I can still run Windows code I wrote in 1998.. How about you, Linus?
Re: (Score:2)
You can? Interesting, for all 16bit applications and even some 32bit ones I'd have to fire up a VM with Win2k by now if they didn't run in WINE.
Re: (Score:2, Informative)
The same cannot be said for Linux, which has a nasty habit of deprecating and dropping support all over the place. Which means without the source code the longevity / viability of any program under Linux is only as long as the current support cycle for it's dependencies. (See also why there are so
Re: (Score:3)
The same cannot be said for Linux
Of course it can. Linux can run 16 bit Windows software, either in dosbox or Wine.
I did a quick test -- downloaded a 16 bit CLOCK.EXE from here [archive.org], typed "wine CLOCK.EXE" ... and it just worked.
Re: (Score:2)
Yep, as long as it's a real Win32 application. It was possible to build applications for 1993-era Windows NT that will still run today, unmodiifed, without VMs or special compatibility tweaks.
That's not a trivial feat on MS's part, and they don't get enough geek cred for pulling it off. Likely because the same fanatical dedication to legacy compatibility has also allowed security vulnerabilities to linger for decades. Still, MS has done right by their users in ways that Linux has not.
Re: (Score:2)
The operative word there is "possible." In practice I have many win32 programs from the 90s and early 2000s that either don't run or don't run properly. Microsoft used to put more effort into backwards compatibility than they do now. Although even that effort often fell short. XP had the VDM that could in theory run DOS software and provide hooks to allow emulated hardware like sound blasters, in practice it didn't actually work all that well and they ceased development of it. We were told Vista would run s
Re: (Score:2)
By far the #1 cause of these headaches is VB6, which was used to write a large number of Windows applications over the years that many people would still like to use. VB6 applications will often still run fine, but their installer was a Win16 program. So you have to write a batch file to copy the files manually and register all the .OCX components with explicit regsvr32 calls.
Big pain in the ass, but at least it can (usually) be done with enough tinkering.
Re: (Score:2)
Most Windows applications written in 1998 were 32-bit, if my memory isn't failing.
Re: (Score:3)
At least for now, you will be able to build a kernel with support by enabling "broken" drivers.
Re: (Score:2)
You can still use the f_ncm gadget. If the OS descriptor is set to WINNCM, Windows 7 and later should automatically install the relevant network driver.
Re: (Score:2)
In general I don't think you can do this. USB is a host/device protocol so one of the machines would have to have a USB port that supports being a device. I don't think USB A has enough pins, so if it's not a mini/micro/C port you're definitely out of luck.
Re: (Score:2)
Ultimately, these things are just a bit of code that packs outgoing IP frames into USB frames and reconstitutes incoming ones. You could use an RNDIS user space driver or kernel module (I think these already exist), or you could switch to using some flavour of CDC.
Using CDC might require upgrading the OS on the pi, or maybe just loading a kernel module or user space driver.
Re:Wait a sec (Score:5, Informative)
RNDIS is close to CDC-Ethernet that for a long time, they were both handled by the same code. However, the two serve different purposes. RNDIS uses USB as a network link - both the USB Host and USB Client form two nodes of the network. You gave each end an IP address and you could communicate as normal.
CDC-Ethernet was designed as a single endpoint - the USB client was a communications device while the USB host was the endpoint. So the USB host would have an IP address, while the USB client would be say, an Ethernet adapter. This was commonly the protocol used for say, cable modems and such - you plugged your PC into the USB port and it showed up as an Ethernet card.
So they're similar, but different. RNDIS is for two hosts communicating over USB, while CDC-Ethernet is for a host to interface to a device that can handle Ethernet packets but is technically not an endpoint.
RNDIS is really an alternative to the other way to do it - which is USB-serial and then you run say, PPP over the link to establish a network connection.
In summary, RNDIS is host to host network connectivity using USB.
CDC-Ethernet, a related and similar protocol is a class driver to connect a USB host to an Ethernet-like network.
Re: (Score:2)
Not sure about that. I just plugged a pi into an Ubuntu machine. They can both ping each other's IP addresses, and either side can initiate an ssh session. The Ubuntu machine is using CDC-ECM.
RNDIS may very well do a bunch of Microsoft things, but CDC-ECM does exactly what the OP wants: creates a virtual ethernet adapter and sends and receives packets through it over the USB connection to a similar driver on the other side.
Something from Microsoft that is broken? (Score:3)
Re: (Score:2)
Yes, and how this was allowed in is beyond me. I looked around and the module seems to be "rndis_host.ko".
So I went looking, on Slackware 15, rndis is set as a module and it is not loaded on boot. So I will create /etc/modprobe.d/rndis_host to blacklist that module.
Re: (Score:2)
Yep. Available evidence suggests rather strongly that MS messes it up far often than not and quite frequently they mess it up fundamentally so it cannot be fixed. These people are a disgrace.
RNDIS was the only plug and play interface I got t (Score:1)
https://wimsworld.wordpress.co... [wordpress.com] Had me going through several options on my cellular modem. RNDIS was the only one that came up directly via dhcpd for both ipv4 and ipv6.
Re: (Score:2)
Then you can't make it secure without breaking the protocol.
Re: (Score:2)