back to article This is what a root debug backdoor in a Linux kernel looks like

A root backdoor for debugging ARM-powered Android gadgets managed to end up in shipped firmware – and we're surprised this sort of colossal blunder doesn't happen more often. The howler is the work of Chinese ARM SoC-maker Allwinner, which wrote its own kernel code underneath a custom Android build for its devices. Its Linux …

  1. Anonymous Coward
    Childcatcher

    Whoops

    Even I can see that is not a good idea from the code. Still: 3.4? That's soooo last months ago.

    However, it isn't old, by a long shot, for a vendor *ahem* supported kernel and I notice all the affected devices are not RPis and yet have similar names.

    What the hell is an Armbian thingie anyway *Google* hmmm English as a second language on the sparse website.

    Wonder why this article appeared ... 8)

    1. Anonymous Coward
      Anonymous Coward

      Re: Whoops

      Be thankful the version number starts with a 3: I know of firms that ship supported kernels with version numbers beginning with 2!

      1. Solmyr ibn Wali Barad

        Re: Whoops

        You mean Red Hat enterprise kernels? They keep major version at 2.6, quite intentionally. Most of the 3.x and 4.x developments are rolled in under minor revision numbers.

        1. Anonymous Coward
          Anonymous Coward

          Re: Whoops

          Nope, I mean ARM chip vendors. Freescale for example.

          1. Solmyr ibn Wali Barad

            Re: Whoops

            Well, if they provide security and stability patches, then 2.x kernel shouldn't be problematic.

            1. Anonymous Coward
              Anonymous Coward

              Re: Whoops

              No, not problematic if as you say, they provide security and stability fixes. That's a big IF.

              Not problematic if the older kernel has the drivers and interfaces you need. Another big IF.

              My experience with Freescale hasn't been so great. The chips are fine. Wonderful even.

              About 6 years ago, I was working for Jacques Electronics, doing embedded work. They were using KaRo TX27 modules, based on the iMX.27 SoC. Latest kernel at the time was 2.6.33, but KaRo were shipping a slightly patched Freescale kernel: release 2.6.28, which was at the time at least a year old.

              The older kernel lacked support for the I²S multiplexer present on the iMX.27. I wound up backporting ALSA from kernel 2.6.33. (There was a lot of video stuff they were using that simply wasn't ported to the newer kernel.)

              Then more recently, different company, now with VRT. We bought some Technologic Systems TS-7670 industrial computers. We found the stock kernel (2.6.35):

              - was flaky on the supplied units with regards to USB

              - suffered buffering issues on serial ports at low baud rates (which played havoc with M-Bus)

              A port to kernel 4.2 was trivial, and the devices in the field now run that.

  2. Brian Miller

    Wrong string search?

    Maybe the devs fixed all of the "TODO"s in the code, but this wasn't a todo...

    This is why wrapping dangerous things like this in #ifdef's is a good idea.

  3. johnaaronrose

    Mr

    2 questions:

    1. I have a Fusion5tablet (which is rooted) manufactured by Allwinner with sun8I chipset using kernel 3.4.39. The file /proc/sunxi_debug/sunxi_debug is zero length. If the code is present, which file (if any) would it be in?

    2. When using Terminal Emulator, I do 'rm /proc/.sunxi_debug/sunxi_debug', I get "Permission denied". 'sudo su' gets "sudo: not found". How do I delete the /proc/sunxi_debug/sunxi_debug file?

    1. Paul Crawford Silver badge

      How do I delete the /proc/sunxi_debug/sunxi_debug file?

      You can't.

      It is not a real file, but part of the the device driver's internal memory that is presented as if it were a file.

      That is how the UNIX model works, everything is a "file". You can access the keyboard and terminal as stdin and stdout, etc (same as Windows there). Hard disks appear as /dev/sda and the partitions on them as /dev/sda1 and so on, serial ports as /dev/ttyS0, etc, etc.

      1. Anonymous Coward
        Joke

        Re: How do I delete the /proc/sunxi_debug/sunxi_debug file?

        I've come to a reconciliation with "everything is a file", but only if we can rename it to something else. Like "link" or "ethereal thingybob". ;)

        1. Stoneshop
          Coat

          Re: How do I delete the /proc/sunxi_debug/sunxi_debug file?

          but only if we can rename it to something else. Like "sandpaper" or "chisel".

    2. Bill Michaelson

      Re: Mr

      I think you'll need to exploit the vulnerability to remove it. Write the magic string to the device to become root, then you can remove the device from the FS. Then abandon your root privilege.

      Something like that.

      1. Anonymous Coward
        Anonymous Coward

        Re: Mr

        Write the magic string to the device to become root, then you can remove the device from the FS.

        /proc is a virtual filesystem, you cannot "delete" files from it.

    3. Lennart Sorensen

      Re: Mr

      The only way to remove it is to patch and rebuild the kernel without the code that creates it. /proc is virtual and not a real file system you can change.

      And the file is 0 length since you activate it by writing a string to it (with echo for example). Since it is virtual, the file size will not change from doing this.

  4. johnaaronrose

    Vulnerable?

    Please explain how I can write the magic string to the file. Also, what is the magic string?

    1. Dwarf

      Re: Vulnerable?

      @johnaaronrose

      I take it you didn't read the article then ?

      1. johnaaronrose

        Re: Vulnerable?

        I did read the article but I did not see a reference to "magic string" in it. Is that "rootmydevice" > /proc/sunxi_debug/sunxi_debug"?

        1. Chemist

          Re: Vulnerable?

          echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug"

          The echo is really quite important

          1. Doctor Syntax Silver badge

            Re: Vulnerable?

            "The echo is really quite important"

            And if you don't know why it's important it's one of many things you should find out first. Another is why, having done that, you should NOT then enter commands such as rm -rf /

            Becoming root on a Unix-style device gives you the ability to do many things, some of which are ill-advised and destructive to the device's software.

            Learn first.

            Actually, one of the best ways to learn is to set up a Linux instance that you can treat as disposable in a VM.

            1. Pirate Dave Silver badge
              Pirate

              Re: Vulnerable?

              "Actually, one of the best ways to learn is to set up a Linux instance that you can treat as disposable in a VM."

              I dunno. I think if you REALLY want to learn, you have to at least once accidentally do "rm -rf *" when you think you're in /var/sometestdir but you're actually in / on a production system. You NEVER forget that lesson... always, ALWAYS do a pwd before an rm -rf .

              1. PeteA

                Re: Vulnerable?

                I'm 48 ... I was 17 when I made the mistake... I haven't forgotten...

            2. HieronymusBloggs
              Joke

              Re: Vulnerable?

              "Learn first."

              That's so last century.

    2. Anonymous Coward
      Anonymous Coward

      Re: Vulnerable?

      From the article: 'As tkaiser writes, echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug" "from any process with any UID will get root'

  5. Tomato42
    Facepalm

    and that's why you should always deploy code only after it goes through upstream review and merge

    but some ARM device makers still "know better"

    1. Gene Cash Silver badge

      Hahaha. I've personally seen stuff like this get missed by "upstream review and merge"

      IMHO that process has become yet another Agile/DevOp tickbox that doesn't mean anything any more.

      1. Justin Clift

        One of the points of having upstream review/merge is to have more people notice otherwise-obvious problems like the code here.

        It's definitely not a perfect approach, but having more people review stuff instead of less is generally a good idea (as long as it doesn't lengthen the developer iteration time too much, which causes other problems).

  6. Paul Crawford Silver badge

    Writing to /proc as user?

    Why are user processes, presumably in some sort of sandbox for protection against dodgy stuff, allowed to *write* to /proc? Often disabling access to /proc except for your own process ID is one of the standard AppArmor settings.

    Just trying to stand back from this massive FAIL and look at the bigger picture of system protection. Oh, and while we are at it, can someone beat the Chrome and Firefox dev teams until they start using and maintaining a tight AppArmor profile as well?

    1. Chemist

      Re: Writing to /proc as user?

      "Why are user processes, presumably in some sort of sandbox for protection against dodgy stuff, allowed to *write* to /proc? "

      Quite - although (for example) in my copies of OpenSUSE only ~ 3 entries are writable - and that only by root. True also for the pi(s) with one exception.

    2. joeldillon

      Re: Writing to /proc as user?

      I would assume that specific file was made writable by ordinary users specifically because it's a debug thing intended to root your device (and Android by default does not allow you root access if I recall correctly).

      1. Paul Crawford Silver badge

        Re: @joeldillon

        I don't men the read/write permissions of individual /proc entries, I mean the lack of sand-boxing of all user process to mask such FAIL! cases as reported here.

        1. joeldillon

          Re: @joeldillon

          It's the kernel. It can do anything. The kernel can't sandbox against itself when the specific purpose of the kernel developer is allowing non-root users to become root.

    3. Peter Gathercole Silver badge

      Re: Writing to /proc as user?

      You know, it used to be that the correct user of permissions, separate UID and GIDs for applications, and the standard UNIX permission model was deemed sufficient to protect from most application programs, without a sandbox.

      The whole idea of sandboxes came about on other OSs, which needed the OS to be protected from applications.

      I appreciate that modern sandbox implementations allow resources to be fenced as well as access, and also that chroot used to be commonly used to give more protection, but still the assumption that a sandbox is required on a Linux system suggests that there is something wrong in the implementation or configuration of the systems (and that is what the article suggests).

  7. MrRimmerSIR!

    At least they have bothered putting kernel code in Github

    Unlike Mediatek. Still violating GPL after all these years.

    1. Michael Habel

      Re: At least they have bothered putting kernel code in Github

      Unlike Mediatek. Still violating GPL after all these years.

      Or possibly AMLogic, or Rockchip.. I guess it must be a Chinese Firewall thing...

      1. MrRimmerSIR!

        Re: At least they have bothered putting kernel code in Github

        You're right. I only mention Mediatek cos I have phones with MTK chips that can't be provided with custom ROMs due to lack of source code.

      2. Anonymous Coward
        Anonymous Coward

        Re: At least they have bothered putting kernel code in Github

        It's probably more of a China thing. The only important thing there is getting the job done. Consumer protection and after-sales service? No chance.

  8. DropBear
    Joke

    No idea why all the backlash - look, they even used "strNcmp" to stay perfectly safe...

    1. Paul Crawford Silver badge

      Also is allows "rootmydeviceyoubunchofuselessfuckers" to match..

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like