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 …
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)
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 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?
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.
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.
"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.
"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 .
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).
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?
"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.
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).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
