
Back door found in Allwinner Linux kernels - tbrock
http://www.theregister.co.uk/2016/05/09/allwinners_allloser_custom_kernel_has_a_nasty_root_backdoor/
======
userbinator
Especially after seeing that "root _my_ device" 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](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.

~~~
IshKebab
The post you linked is very different - it appears to require user
interaction, which is a perfectly ok way to allow root access.

This allows _any app_ to gain root. _Without user interaction._ That is
insane.

~~~
unlinker
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".

~~~
ArkyBeagle
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]

~~~
__jal
Are you confusing "normal" with "desirable"?

The update treadmill is normal, in the classic sense of the word.

~~~
ArkyBeagle
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.

~~~
unlinker
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.

~~~
ArkyBeagle
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.

------
consp
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.

~~~
jws
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.)

~~~
userbinator
_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.)

------
andrey_utkin
> Although it doesn't appear to have made it into the mainstream kernel source

Now, who wants to blame upstream kernel maintainers for not merging in all the
dirt around and requiring high quality of code submissions?

~~~
makomk
_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.

~~~
IshKebab
If only drivers were cleanly separated from the kernel like they would be on
any sane OS...

~~~
makomk
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.

------
kazinator
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.

~~~
chadcatlett
It is created with 0666 as the mode. [https://github.com/allwinner-
zh/linux-3.4-sunxi/blob/A83T/ar...](https://github.com/allwinner-
zh/linux-3.4-sunxi/blob/A83T/arch/arm/mach-sunxi/sunxi-debug.c#L69)

------
dfritz
And everything hidden in this undocumented monster-commit:

[https://github.com/allwinner-
zh/linux-3.4-sunxi/commit/7cc9a...](https://github.com/allwinner-
zh/linux-3.4-sunxi/commit/7cc9a8fff679fcd31bca7d18c8b3b960796d032f)

He should have added:

3\. add a backdoor;

~~~
dfritz
I like how the repository's history was discretely rewritten since then.

Commit 7cc9a8fff679fcd31bca7d18c8b3b960796d032f was replaced by
bcc3e09783ca31039183d5084d8480bd76d531f5, without the sunxi-debug.c file.

Compare [https://github.com/allwinner-
zh/linux-3.4-sunxi/commit/7cc9a...](https://github.com/allwinner-
zh/linux-3.4-sunxi/commit/7cc9a8fff679fcd31bca7d18c8b3b960796d032f) (original)
with [https://github.com/allwinner-
zh/linux-3.4-sunxi/commit/bcc3e...](https://github.com/allwinner-
zh/linux-3.4-sunxi/commit/bcc3e09783ca31039183d5084d8480bd76d531f5) (modified)

[https://github.com/allwinner-
zh/linux-3.4-sunxi/blob/7cc9a8f...](https://github.com/allwinner-
zh/linux-3.4-sunxi/blob/7cc9a8fff679fcd31bca7d18c8b3b960796d032f/arch/arm/mach-
sunxi/sunxi-debug.c)

[https://github.com/allwinner-
zh/linux-3.4-sunxi/blob/bcc3e09...](https://github.com/allwinner-
zh/linux-3.4-sunxi/blob/bcc3e09783ca31039183d5084d8480bd76d531f5/arch/arm/mach-
sunxi/sunxi-debug.c) → 404

~~~
koja86
Fortunately there are un-modified forks. Created one more just for evidence:
[https://github.com/koja/linux-3.4-sunxi](https://github.com/koja/linux-3.4-sunxi)

------
wicket
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.

------
0x0
Funny to see how it spreads
[https://github.com/search?q=rootmydevice&type=Issues&utf8=%E...](https://github.com/search?q=rootmydevice&type=Issues&utf8=%E2%9C%93)

~~~
lamarkia
This is a search on the github issues, and not on the source code.

~~~
0x0
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.

------
alwaysdownvoted
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.

~~~
djsumdog
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)

~~~
yuhong
What is awful about that one is that they even skip microcode updates.

------
y04nn
Just tested it on Orange Pi, it's too easy. Does that means that all Allwiner
based tablets and phones are vulnerable?

~~~
lamarkia
It was a debug feature that was left enabled in the kernel source for H3 and
newer cpus.

They should have done #ifdef DEBUG in the kernel source...

------
jjawssd
This is excellent news for those that value individual freedom and the right
to modify the devices you paid for.

~~~
Manouchehri
It's a bit more than individual freedom.

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.

------
hbrid
Please turn JavaScript on and reload the page.

DDoS protection by CloudFlare

...um, no!

~~~
raverbashing
I don't see why Cloudflare would require JS to be on

~~~
Ambroos
It's what they use to try and detect if your browser is a real browser, not a
fake one. Which is very hard to determine without Javascript.

~~~
raverbashing
It looks like an important goal

Maybe they can do it better and not turn people without JS away (at least
while accesses are at a regular level)

------
wicket
Anyone know how long the Allwinner kernel source had been available for before
this was discovered? They were previously known for GPL violations.

~~~
Manouchehri
The source was shared in June 2015. It could have been later though, Allwinner
tends to rewrite their Git history.

Thomas Kaiser appears to have been the first person to discover it on April
29th, 2016. [http://irclog.whitequark.org/linux-
sunxi/2016-04-29#16314390](http://irclog.whitequark.org/linux-
sunxi/2016-04-29#16314390) (Thanks to HD Moore for linking me.)

From what I can tell, it went unnoticed for slightly under a year.

------
hathym
[http://irclog.whitequark.org/linux-
sunxi/2016-04-29#16314390](http://irclog.whitequark.org/linux-
sunxi/2016-04-29#16314390)

(search for rootmydevice)

------
jamiesonbecker
The best backdoor is the backdoor that is labeled _debug_.

------
cia48621793
This is China.

------
markokrajnc
Chinese espionage at work... I wonder how many foreign agencies can access my
phone: USA, UK, China, Russia, ...

~~~
danieldk
Hanlon's razor applies here, but guising backdoors as programming/deployment
errors gives plausible deniability.

~~~
Arnt
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.

~~~
0x0
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).

~~~
Arnt
That's orthogonal.

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.

~~~
0x0
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"? :)

