Announcement

Collapse
No announcement yet.

Linux Still Working To Disable RNDIS Drivers In 2024

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    As long as it's not submitted, a sysconf/kernel config would be a lot better though...

    Comment


    • #32
      Feature loss is always a shame, always... But people getting upset over what they deem "theoretical" or "in the lab" vulnerability really should just do a google search before spewing nonsense. There are many exploits available... And it's a bit hard (to put it naively) to mitigate an exploit which is based on using the protocol as intended...

      So again, as much as I don't like feature losses, this is evidently based on something real. And the problem is that the kernel autoloads modules so you want that not compiled in nor provided as a module... Distros are free (so far) to still compile it in and probably blacklistvit by default. If they did that, there would be no talk of removing it. But they don't because people just complain that their tethering is broken on their 5-year-old phone and won't even try to understand that "conformant" usb devices could dump system memory without them noticing. Their *phone* could do that if compromised... And given the very bad security track record of phones (especially the outrageous lock-in and short security support), the probability of that happening is non-zero, with dreadful consequences.

      Comment


      • #33
        Well, this is just a quick google search, so maybe there are things that are not so easy, but... it seems that it's possible to create a network driver in user space (https://www.net.in.tum.de/fileadmin/...rk-drivers.pdf ) and the usb library should allow to implement the other part also in user space, so... maybe it would be a good idea to create an user space RNDIS driver and get that thing out of the kernel.

        Comment


        • #34
          Originally posted by Brittle2 View Post
          how do i know if my cell require this driver?
          i'm not sure if this is the right way to do it, but i tested it out by blacklisting the rndis kernel module
          Code:
          echo 'blacklist rndis_host' > /etc/modprobe.d/rndis.conf
          , rebooting and trying out usb tethering. can confirm, on my samsung phone running android 13 it does not work. unblacklisting it made it work again

          Comment


          • #35
            Originally posted by User42 View Post
            Feature loss is always a shame, always... But people getting upset over what they deem "theoretical" or "in the lab" vulnerability really should just do a google search before spewing nonsense. There are many exploits available... And it's a bit hard (to put it naively) to mitigate an exploit which is based on using the protocol as intended...

            So again, as much as I don't like feature losses, this is evidently based on something real. And the problem is that the kernel autoloads modules so you want that not compiled in nor provided as a module... Distros are free (so far) to still compile it in and probably blacklistvit by default. If they did that, there would be no talk of removing it. But they don't because people just complain that their tethering is broken on their 5-year-old phone and won't even try to understand that "conformant" usb devices could dump system memory without them noticing. Their *phone* could do that if compromised... And given the very bad security track record of phones (especially the outrageous lock-in and short security support), the probability of that happening is non-zero, with dreadful consequences.
            I assume you are talking about CVE-2022-25375. That was patched back in 5.17, and presumably backported as well.

            Comment


            • #36
              Originally posted by ahrs View Post
              Yes, it will. To quote the Gentoo Wiki:


              So have a device older than two years old? Eff you.
              Whenever this change hits the mainline Linux kernel, you're not forced to upgrade to it or use it. Just stick with a older LTS kernel. Security and other updates still get backported to older kernels.

              Comment


              • #37
                Originally posted by sophisticles View Post

                Great idea, i say anything from Microsoft should be removed from the Linux kernel, for instance exFAT support.
                Why stop there? Let's also remove the FAT and FAT32 driver and the read-only NTFS driver from the kernel, as well as NTFS support from FUSE.

                While we are at it, might as well also axe the RFC for the NTSYNC primitive driver.
                Last edited by Sonadow; 19 February 2024, 09:30 PM.

                Comment


                • #38
                  Originally posted by direc85 View Post
                  I have a few use cases which include a Linux computer, a USB cable and a smartphone. I'll try to build my kernel with the patch and see what works and what doesn't.

                  Disabled by default would be a better choice, removing the driver altogether would break a lot of not-so-ancient devices, which "offends" Linux's otherwise so pristine backwards compatibility. We'll see...
                  Save yourself the effort, i'll tell you right now that USB tethering won't work.

                  Comment


                  • #39
                    android-udev-rules repo maintains a large collect of devices. https://github.com/M0Rf30/android-ud...oid.rules#L214 indicates that ONLY Google Pixel 7/7Pro/6/6A/6Pro use cdc-ncm

                    Comment


                    • #40
                      Get lost, Greg.
                      I am relying on this and i am perfectly able to deal with those "muh security vulnerabilities".
                      Hell, the only phones that support the replacement (ncm) are current Google Pixels.
                      And Google didn't remove rndis out of their kernel either.

                      Comment

                      Working...
                      X