Especially after seeing that "rootmydevice" string in the code, I think there's much to be said for this in relation to today's world of locked-down devices which resist control from even their owners. Given that their SoCs are meant for such devices, maybe it's AllWinner (or someone at the company)'s way of rebellion against that. If so, I'm glad that there are still people out there who do not believe in the user-oppressing culture of "security" that seems to have become the norm and are actually trying to do something about it. Maybe it really was just a debugging oversight, but either way, I'm not outraged by it --- contrary to what the media seems to say. This is a local privilege escalation for software intended to run on a device that you --- and only you --- are supposed to own anyway.
Relatedly, here is a post 6 years ago by someone putting in a root backdoor in a device he designed --- and explaining how to use it:
http://www.bunniestudios.com/blog/?p=1140
If that was today, someone would discover it, scream "backdoor! security vulnerability!", and it would be all over the news like this one. And that makes me very sad.
In any case, a huge amount of Android devices out there run outdated versions of the kernel, drivers or Android itself with privilege escalation vulnerabilities.
The only thing that is insane here is that we all deem this as "normal".
So the update treadmill is normal? That's a very weird thing to assume is normal.
"Well, in our country," said Alice, still panting a little, "you'd generally get to somewhere else—if you run very fast for a long time, as we've been doing."
"A slow sort of country!" said the Queen. "Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!" [1]
I don't consider it normal behavior. It's obsessive in its very nature. But I understand that systems cracking and malware writing are pernicious, antisocial behavior, and should be addressed with heads on pikes outside the city wall.
You say it's antisocial behaviour like they do that just for the sake of it, when there is money to be made. Like sending spam, etc. You want a botnet? Then compromise stuff, and then use the botnet for your benefit. It's not antisocial in any way.
Like making money is a justification. So now we're up to their head and their entire family's head on a pike.
Taking over something and operating it without permission is highly congruent with naval piracy. So perhaps hung from the yardarm is better. At any rate, something gruesome, public and nasty needs to happen to them.
Yes, I think the basic ... drive to do this is just latent in people, and they initially did it just for the heck of it. There was no money in it to start with.
How this could be considered anything other than deeply antisocial is beyond me.
Allwinner chips are lockdown-free even without this - you just need to hold down the right button/pin at poweron and the ROM bootloader goes into a mode that lets you load unsigned code over USB. This kernel code is simple incompetence.
> Allwinner chips are lockdown-free even without this - you just need to hold down the right button/pin at poweron and the ROM bootloader goes into a mode that lets you load unsigned code over USB.
Side-loading unsigned 'ROM's/packages and gaining root are orthogonal concepts in Android: sometimes you want to obtain app-level root in the factory-installed OS - sideloading won't help with that (unless you are side-loading a rooted ROM, but that is not a given)
The boot ROM's recovery mode lets you load arbitrary code into RAM and then boot it. The conventional way to use this is load a flasher program that you then use to flash a new OS image, but you can use it to run any Linux kernel and and software of your choice purely from RAM, which can then do what it likes to the existing OS install. See http://linux-sunxi.org/FEL/USBBoot
> you can use it to run any Linux kernel and and software of your choice purely from RAM
As I said: sometimes you just want to run 1 app as root, not replace the kernel. Also, good luck getting a usable device with your own kernel/software when chip manufacturers don't provide drivers: unless you don't mind the usual litany of XDA caveats ("N0irROM v.0.4. Not working: Camera, GPS, Hardware acceleration. new: mic now working, randomly reboots less often")
I'm glad that there are still people out there who do not believe in the user-oppressing culture of "security" that seems to have become the norm and are actually trying to do something about it.
You mean, like Google? Nexus devices can be rooted just fine. They just don't give root permissions to any app without asking or even informing me.
Well... they were mostly know for GPL violations and less-than-propper support for everything they claimed (try reading the SoC spec for the A20. If you can find it. Other examples include GPS support, proprietary drivers without support, not releasing sources, etc.).
But apparently they stepped up their game. Even for debugging this is an odd one.
They tell you the names of many registers. What more do you want?
(I really miss the old days when you got a document that explained everything about your processor. I have an ARM port of an experimental OS waiting for a new board with a complete data sheet. It's been a year so far.)
try reading the SoC spec for the A20. If you can find it.
Googling "AllWinner A20 datasheet" brings in good results.
"Broadcom BCM2836 datasheet" doesn't. All you get is part of the GPIO registers, and absolutely NO electrical specifications. (Part of me really wants someone working there to "take one for the community" and leak the full datasheet. Ironically, that's how the AllWinner docs were originally released.)
raises hand Me! I actually run the upstream kernel on an Allwinner device and was looking into why certain audio features weren't enabled. Turns out that someone had written a patch and it'd got stuck in kernel-patch-submission hell, including mutually conflicting requirements from the ALSA and ARM SoC maintainers. This seems to be basically the norm from what I've seen - endless bikeshedding, vague and changing requirements, and other delays that make it almost impossible to get support for modern SoCs merged before they're long obsolete.
I think upstream support for the chips affected by this got stuck in long arguments about the most elegant way to support their clocking and reset infrastructure, which needs to be solved before actual peripheral drivers can be developed. The H3 seems to be approaching the point where it has enough upstream support for a handful of limited uses, over a year after the mainlining effort started. The A83T is still held up on getting the support code necessary to actually boot Linux merged.
That was a nice idea back in the days when hardware was made up of discrete, standalone single-purpose peripherals. Unfortunately there's no such thing as "cleanly seperated" anything in modern SoCs - everything's interdependent. For example, the main USB controllers on Allwinner chips are basically standard EHCI, same as on any PC, except they also rely on the centralized Allwinner clock-generation and reset block and the Linux EHCI driver has to co-operate with the driver for it. There's a whole bunch of shared infrastructure within Linux to make this possible which has to be updated from time to time due to new requirements.
I think modern Intel chips are similar, except that they run closed-source management firmware to help them look more like a collection of separate devices to Windows - but they aren't and Skylake can't enter lower CPU power states unless the SATA link is in power-saving mode and a whole bunch of other peripherals co-operate because they share hardware. ARM SoCs just don't have the magic firmware that lets the drivers hide this from the OS.
If it was, all you'd have would been opaque Allwinner stuff like this one, complete with backdoors. While I agree with you on a theoretical level, upstream is the only sanity check we have right now. Also, once upstreamed code generally keeps working, but out of tree drivers tend to get bit rot fairly quick.
While I do agree that Linux is partly to blame for this fiasco, we are also in a different world.
Who is responsible for the fact that an active I2C device prevents entering sleep state 0 but an active SPI device does not? Where does that information get recorded? And who needs to act on it?
On the RPi, you can change pin direction without being in supervisor mode--that's not true on the BeagleBone.
These aren't easy questions, and the Linux architecture makes it even harder.
What are the permissions on /proc/sunxi_debug/sunxi_debug?
Anyone know?
This could be locked down so that, say, only processes which are members of a certain group can open a file descriptor to this proc entry.
This is a lot of unnecessary effort to implement something that can be obtained with a simple /bin/rootmydevice executable that is chmod u+s. (Though it is somewhat more streamlined: no intervening process execution is required).
Which, in turn, is a lot of effort to reinvent sudo.
(But of course, those are arguably front doors; you can easily scan the filesystem image for items that have u+s perms.)
I would do this kind of hole differently: why not just hack the kernel so that any process can do setuid(0). Or, slightly hide it: say, setuid(-42) gives you root privs.
There's even a bug in this back door (assuming The Register accurately copy and pasted). They're setting the effective UID to 0 twice instead of setting saved GID to 0. Not that it makes much difference but it does show a further example of their incompetence.
You can click on "code" to see the source code copies. I found these issues more interesting as it seems the different repo admins have wildly different approaches to responding.
I like to compile and install my own OS images on the hardware I purchase. Of course the smartphone industry does not make that easy, if at all possible.
Hence I am forced to choose other form factors.
It would be nice to flash my own choice of BIOS. As far as I can tell this is still not too common. That is a project to which I am willing to devote large amounts of time should the information needed ever become public.
It seems the newer the hardware the more complicated and difficult this becomes. By my estimation, there is certain value in older hardware because it is not as complicated and can be easier to control.
Here is an idea that stays with me year after year: another open source OS project that chooses a single item of hardware and supports only that item.
Silly fantasy: Perhaps a deal is struck with one or more factories that can produce it. Perhaps the terms could be public. Maybe user-developers become faithful and loyal buyers of the hardware, because they like the control. Perhaps they directly pay the costs of production through donations. I have no idea what would happen. That's the point of trying it.
Building this sort of symbiotic relationship between open source user-developers and a single hardware manufacturer based on a single item, one could reason it is in the best interest of the manufacturer to open the specs to the developers, if not the public.
I leave it to you to list all the many reasons this is not worth doing. Then sit back and enjoy the status quo.
But for those of you who are avid users of an open source OS, I ask you to consider:
Do you ever get tired of watching the project trying to keep pace with new hardware? How do you feel about when the manufacturers will not disclose the specs? Are you OK with binary blobs in your "open" system? How about not knowing whether your OS of choice is going to work with your new hardware? What if there was one item of hardware that you could be absolutely sure was always going to work with your preferred open source OS, and to its maximum capacity?
OK, you may now return to chasing the new (locked-down) hardware. Thank you for your time.
Stallman has a post about his Thinkpad X60, one of the very few laptops where you can install a totally open BIOS.
The Librem laptop was another attempt at this, but it failed pretty badly. They couldn't get around a lot of the "binary blob" issues with modern hardware. They're attempt may in fact show that truly open firmware on modern x86_64/amd64 machines may be impossible.
There's Novena, but I believe that's ARM based (which is possibly the best bet for truly open hardware today)
Out of curiosity, what form factors do you choose for (smart)phones? And in general, what open hardware do you know of that can be used with the knowledge that it doesn't have binary blobs/whatever else that could be spying on the user of the hardware? I've recently become more interested in this topic, and am personally considering moving more in the direction of open software and hardware after finding out about the awful stuff Lenovo does.
The permissions are set to world writable, so you're giving every app the right to modify your system.
I'm still not sure why Allwinner resorted to this silliness instead of using su like a sane developer. If anyone could loop me in that would be appreciated.
EDIT: Why did someone flag this? This is literally what CloudFlare said they do – they fingerprint your browser, to track you, and find out if you are a bot DDoSing them – or if you have a normal browsing behaviour.
For that to work they need to fingerprint and track you. Which is why they said they block users with NoScript or on TOR.
I haven't looked into it, by my assumption has always been that they've kept certain modules and interfaces as closed-source, but that big chunks of the kernel were open (or that the kernel was closed for some of their SoCs and at least partially open for others, or some similar combination).
I may be wrong on those points. Maybe someone can correct me.
Guise? They distributed source and the patch is not at all obfuscated. Eight consecutive lines like "cred->uid = 0;" and then printk("now you are root\n"), so it's really easy to spot in a diff.
Don't see why they did it, but they did in in the plainest and most visible way I can imagine.
They distributed source and the patch is not at all obfuscated.
Which is exactly my point.
Say you are a government organization that requires a backdoor. You can make a very sophisticated backdoor. When it's found it is clear that it is probably an intentional backdoor (e.g. Dual_EC_DRBG). Or you can make a very obvious backdoor that is disguised as a debugging option that you forgot to disable, an obvious logic error, etc. For such backdoors, it's easy to argue that it was just sloppy programming (in contrast to an intentional government-requested backdoor), so people will assume the simpler explanation (as in Hanlan's razor).
We have learned from the Debian OpenSSL saga [1] that trivial programming errors in critical software can go unnoticed for years. I don't think the Debian OpenSSL bug was government-mandated, but it's easy to see that this is a very attractive route: the bug caused only 32,768 unique private keys to be generated (great for spying), most people will believe it's a true programming error, you pay the person/company that introduces the bug royally for taking the blame.
Assume the printk("You're root now") had not been there. Would that increase your estimate for the probability of an intentional backdoor, or reduce it?
Two rival businessmen meet in the Warsaw railway station. "Where are you going?" says the first man.
"To Minsk," says the second.
"To Minsk, eh? What a nerve you have! I know you're telling me you're going to Minsk because you want me to think that you're really going to Pinsk. But it so happens that I know you really are going to Minsk. So why are you lying to me?"
It's not THAT easy to spot in a diff because a lot of these kernel source code repository dumps are basically 1 single commit with the entire source code; any existing kernel.org git history is lost. So you'll have to figure out which mainline revision they started working from, and manually diff with that (which will probably turn into a huge mega-patch).
What you're saying is that the diffs are hard to work with in general. What I'm saying is that in a diff (be it large or small, a single commit or many), the code they wrote is the most visible and understandable way to do what they did.
What better way to disguise a backdoor than an apparently deliberate "debug" utility? I mean, if they have to distribute source code sooner or later (which they do since Linux is GPL), this looks much more innocent than any super obfuscated "hidden" source code that would be discovered eventually anyway.
Not saying this was the actual intention here, but it'd be a plausible way to go about it. It certainly appears the backdoor is running on lots of devices in the wild before it got noticed (even when it's this obvious in the diff(!)), so "mission accomplished"? :)
If so, it was hidden in plain sight. Using /proc is not something that won't show up over a very short period of time. Especially if you call it sunxi_debug which will at least trigger my interest as an embedded developer.
While in this case the backdoor may have been deliberate or accidental, more generally, Hanlon's razor is a heuristic for harmonious social relations -- not truth-seeking.
There's a lot too say to the whole "the government listens to my calls" etc etc.
If you're after privacy its about op-sec. Turning off the phone, not using it for certain activities, having different phones for different compartments of life.
People (me included) are lazy, and really, if your relying on a phone for your security...well..good luck with that.
Relatedly, here is a post 6 years ago by someone putting in a root backdoor in a device he designed --- and explaining how to use it: http://www.bunniestudios.com/blog/?p=1140 If that was today, someone would discover it, scream "backdoor! security vulnerability!", and it would be all over the news like this one. And that makes me very sad.