Security Alert for Allwinner sun8i (H3/A83T/H8)

[tkaiser]

EDIT: This is NOT about a (hidden) backdoor but just a local privileges escalation that affects one single 3.4 kernel variant for 2 Allwinner SoCs. In case you came here through lurid headlines please read this comment here first and help stop spreading further BS like "all Allwinner devices contain a hidden backdoor" -- the code has been found since Allwinner could be convinced to open their Github repos in the past so everyone is able to audit their Android kernel source!

 

 

 

It has been brought to our attention two days ago on 2016-04-30 in linux-sunxi IRC that Allwinner's 3.4 legacy kernel for H3/A83T/H8 contains a nasty local privileges escalation. Any process running with any UID can become root easily by simply doing this:

echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug

Combined with networked services that might allow access to /proc this means that this is also a network enabled root exploit. As usual we fixed such an issue within a few hours, on May 1st new Armbian 5.10 images were rolled out and in the meantime the fix is also in Armbian's apt repo so please upgrade now (apt-get update/upgrade or start with a fresh OS image) if you're affected! If you're already running Armbian 5.10 then this vulnerability is already fixed.

 

This security flaw is currently present in every OS image for H3, A83T or H8 devices that rely on Kernel 3.4: this applies to all OS images available for Orange Pis (except Armbian 5.10 available since May 1st), any for FriendlyARM's NanoPi M1, SinoVoip's M2+ and M3, Cuebietech's Cubietruck + and Linksprite's pcDuino8 Uno

 

We informed all vendors where possible also two days ago (FriendlyARM and SinoVoip took notice, the others still ignore the issue)

• FriendlyARM: https://github.com/friendlyarm/h3_lichee/issues/1
• SinoVoip M3: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/10
• SinoVoip M2+: https://github.com/BPI-SINOVOIP/BPI-M2P-bsp/issues/1
• Cubietruck +: https://github.com/cubieboard/Cubietruck_Plus-kernel-source/issues/2
• LinkSprite pcDuino8 Uno: https://github.com/pcduino/pcduino8-uno-kernel/issues/3

Users of any of the available OS images for H3 based Orange Pis are somewhat lost since none of the OS images or kernels used for these are maintained any longer. Loboris disappeared (so the opened issue is more like a reference) and Xunlong themselves do not maintain their software at all (not even possible to open an issue there).

 

In case some readers here do also have accounts at Orange Pi forums, please spread the word and inform the users that their OS images are exploitable unless they already use Armbian 5.10. Same applies to Banana Pi forums, please spread the word there also that all M3 and their M2+ OS images are affected (I deleted my account there since talking to @sinovoip is like talking to a wall and just makes me sick, but it might be worth the efforts to try to warn their users)

[theguyuk]

Do they know who designed the problem in the kernal?

[zador.blood.stained]

Do they know who designed the problem in the kernal?

Original BSP kernel is designed for Android, where getting root privileges in "one click" would be very useful for testing and debugging purposes...

... if only there was a simple way (even kernel config symbol!) to disable this for production / public images.

[tkaiser]

Do they know who designed the problem in the kernal?

 

This security flaw has been proudly produced by Allwinner itself: https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/arch/arm/mach-sunxi/sunxi-debug.c

 

As Zador explained there might be good reasons to enable/use something like this while developing, the real problem ist that none of these devs does really care about Linux and 'productive use' (and security at all). That's one of the reasons no one wants to use these BSP kernels since you never know how many surprises like this are hidden in there.

 

Fortunately mainlining efforts for H3 are still progressing nicely so we can throw this Allwinner 3.4 crap in the bin rather sooner than later

[theguyuk]

Well unless it is a problem in Chrome browser on my Android M8 ( S802) TV box, when I just tried the resources tab on Orange Pi Org the downloads, github, wiki links are not working. Wonder if with security problem they have been disabled?

[tkaiser]

Original BSP kernel is designed for Android, where getting root privileges in "one click" would be very useful for testing and debugging purposes...

... if only there was a simple way (even kernel config symbol!) to disable this for production / public images.

 

BTW: The FriendlyARM folks were the only paying attention to this security flaw and now do it exactly that way: https://github.com/friendlyarm/h3_lichee/commit/5d4d02b1c8f336ba002eed4d97dee3a51ea76cdd

[maesstrissimo]

Thanks a lot, tkaiser ! 

[jkx]

@tkaiser, you should bump the package number for Armbian (5.10a..) or something. because the update / upgrade won't force an update right now. 

[tkaiser]

@tkaiser, you should bump the package number for Armbian (5.10a..) or something. because the update / upgrade won't force an update right now. 

 

Sorry, I don't understand. 5.10 contains the necessary fixes for rootmydevice already and there is no more recent version released. What are you asking for?

[jkx]

Sorry, I don't understand. 5.10 contains the necessary fixes for rootmydevice already and there is no more recent version released. What are you asking for?

 

You said, we have to do apt-get update / upgrade to latest 5.10 (2 days old).  I didn't do an upgrade since 3 or 4 days, I'm already w/ kernel package 5.10. so nothing to update .. 

[tkaiser]

I updated the original post with absolute timestamps. I hope it's now obvious?

[tkaiser]

UPDATE: Official Allwinner statement:

 

Allwinner Technology committed to resolving Linux Kernel software issue

Zhuhai, China - Allwinner Technology.Co.Ltd (SHE: CN:300458) is working with its device manufacturers to fix a current software issue. We are aware that code, which was supplied to device manufacturers for the purpose of developing products, should have been removed prior to shipping. We recommend that anyone who is concerned about this issue should contact the relevant device manufacturer.

In relation to the source code on Github, it is released for the open source community only and not for shipping certain devices. Since a debugging function is not needed it has subsequently been removed.

Allwinner is committed to producing quality SoC’s with security a key priority. We are currently working hard to address this issue and revising our current processes so we can continue to evolve our range of SoC’s in the future.

[theguyuk]

I wonder if a miracle will happen and Allwinner learn software support to customers is good business?

 

Titanic might float again first, I suspect.

[tkaiser]

I wonder if a miracle will happen and Allwinner learn software support to customers is good business?

 

I wonder if you're deep enough into intercultural differences to understand anything? At least I'm not and I consider many things that happen in China as a miracle (and I would suspect that's the same regarding us Westerners when looking at us from China).

 

You should be aware that you're not an Allwinner customer and that this whole SBC thing is close to irrelevant for them. The vast majority of their customers produces Android devices and Allwinner supports them as much as they can. Compared to this large Android market the count of Allwinner SoCs used with Linux is laughable (even if you consider customers like Olimex that order tens of thousands for boards used in industrial environment).

 

Considering this I even understand that Open Source proponents inside Allwinner might have a hard time. But it seems there are some since they do release their kernel sources (even if there are some BLOBs inside). Please keep in mind: This whole issue has been discovered since we were able to audit the code (different story is that they could help us with better commit logs and so on but at least looking through nearly all code is possible).

 

I really hope that this incident doesn't stop Allwinner opening even more code (with useable licenses and not just "All rights reserved") since even if the Linux market seems to be small/irrelevant they get so much back from linux-sunxi community (better code, mainline kernel code and also a better reputation since most older Allwinner SoCs run perfectly fine with mainline kernel due to community's work. And support for the most recent ones is progressing nicely. An Armbian image with mainline kernel for H3 boards is not that far away since linux-sunxi community does such a great coding job!).

 

So let's stop speculating/badmouthing and hope for the best instead! 

[theguyuk]

I wonder if you're deep enough into intercultural differences to understand anything? At least I'm not and I consider many things that happen in China as a miracle (and I would suspect that's the same regarding us Westerners when looking at us from China).

 

You should be aware that you're not an Allwinner customer and that this whole SBC thing is close to irrelevant for them. The vast majority of their customers produces Android devices and Allwinner supports them as much as they can. Compared to this large Android market the count of Allwinner SoCs used with Linux is laughable (even if you consider customers like Olimex that order tens of thousands for boards used in industrial environment).

 

Considering this I even understand that Open Source proponents inside Allwinner might have a hard time. But it seems there are some since they do release their kernel sources (even if there are some BLOBs inside). Please keep in mind: This whole issue has been discovered since we were able to audit the code (different story is that they could help us with better commit logs and so on but at least looking through nearly all code is possible).

 

I really hope that this incident doesn't stop Allwinner opening even more code (with useable licenses and not just "All rights reserved") since even if the Linux market seems to be small/irrelevant they get so much back from linux-sunxi community (better code, mainline kernel code and also a better reputation since most older Allwinner SoCs run perfectly fine with mainline kernel due to community's work. And support for the most recent ones is progressing nicely. An Armbian image with mainline kernel for H3 boards is not that far away since linux-sunxi community does such a great coding job!).

 

So let's stop speculating/badmouthing and hope for the best instead!

 

A little thought springs to mind, if I take Aliexpress Orange Pi boards for sale figures and add Banana Pi sale figures, friendlyarm, Olinuxino on just H3 soc that is growing tens of thousands extra sales of H3 soc above and beyond Android use in TV box, Dongle and Tablets.

 

So if these customer buy a extra 70,000 H3 socs is that still a small market to ignore compared to Android millions of sales. Allwinner states the company culture is

 

With the mission of “improving the life quality through value innovationâ€, Allwinner is always in pursuit of excellence to make a sustainable industry leader.

 

Allwinner always sticks to the corporation value of "market-orientation, integrity and responsibility, great execution, courage and discipline, profession and quality, openness and win-win, and persistence", and insists the corporation culture of "teamwork, honest and respect, profession and fairness, faith, openness and curiosity".

 

http://www.allwinnertech.com/en/about/culture.htm

 

Time only has the answer.

[Igor]

With the mission of "*"

 

Corporation mission, vision & marketing chit chat is pure bullshit, spam, if this is more understandable. Nothing to take seriously into account.

[tkaiser]

BTW: Funny example how to deal with 'rootmydevice' on a distro where everything should happen as root anyway: 

 

- http://web.archive.org/web/20161011190545/https://github.com/Fourdee/DietPi/issues/329#issuecomment-253011573

- vs. https://github.com/Fourdee/DietPi/issues/329#issuecomment-218887283

- vs. https://github.com/Fourdee/DietPi/issues/312#issuecomment-253002887

 

I wanted to understand why users who chose to use a distro that does not care that much about security did care about 'rootmydevice' (they are already logged in as root so why do they fear a root exploit?!). Doesn't work, distro maintainer constantly deletes my questions

 

This scares me a bit since censorship is not exactly the right way to address security concerns.

[tkaiser]

On a related note: today in linux-sunxi IRC an Allwinner Github repo has been spotted with kernel sources for Allwinner's so called "Tina OS". Funnily the kernel tree useable for R16 (the same as the already known A33 tablet SoC) still contains the 'rootmydevice' functionality but this time it's disabled by default and needs to be enabled (you would've to set CONFIG_ROOT_DEVICE to enable the debug functionality) 

[Fourdee]

BTW: Funny example how to deal with 'rootmydevice' on a distro where everything should happen as root anyway: 

 

- http://web.archive.org/web/20161011190545/https://github.com/Fourdee/DietPi/issues/329#issuecomment-253011573

- vs. https://github.com/Fourdee/DietPi/issues/329#issuecomment-218887283

- vs. https://github.com/Fourdee/DietPi/issues/312#issuecomment-253002887

 

I wanted to understand why users who chose to use a distro that does not care that much about security did care about 'rootmydevice' (they are already logged in as root so why do they fear a root exploit?!). Doesn't work, distro maintainer constantly deletes my questions

 

This scares me a bit since censorship is not exactly the right way to address security concerns.

 

Thomas,

 

If you can clearly define an issue with DietPi and/or its security, please make a git ticket and we will look into it.

 

In the mean time, I will continue to delete all "hear say" posts with no relevant proof of your claims.

It would also be worth noting, that, only your posts have ever been deleted, in the history of DietPi project.

[rodolfo]

It would also be worth noting, that, only your posts have ever been deleted, in the history of DietPi project.

 

Censorship is ALWAYS wrong. No matter how much you disagree with someone's opinion, the right to voice an opinion is crucial in any civilized discourse. In a weak and decadent world only "nice" people are tolerated, while the dedicated and ambitious ones who actually get things done and are ready to stand up for a cause are loathed.

[Slackstick]

Thomas,

 

If you can clearly define an issue with DietPi and/or its security, please make a git ticket and we will look into it.

Fourdee,

 

Thomas said that "rootmydevice" does not increase security risk at DietPi.  Please enlighten me how fixing this function increased security at DietPi.

 

Thanks.

[tkaiser]

Thomas said that "rootmydevice" does not increase security risk at DietPi.

 

Nah, I said that the whole 'issue' wasn't that much of an issue (especially when using a distro that is designed to be a single-user system where everything runs with UID==0 like DietPi). And that puzzled me -- why do DietPi users who use a distro that is designed to be 'root only' fear 'root exploits'? Was just for my personal understanding and to get stuff publicly documented as it is now.

 

I don't believe any discussion will help. We tried to support DietPi as much as possible over the last 6 months (and we're glad that we could help providing a lot of improvements for DietPi users) but now for me a red line has been crossed (twice). We tried several times to explain why and how Armbian's understanding of security differs from DietPi's (to no avail) and I got a bit angry with Igor since he accepted an absolutely useless PR. But as soon as someone starts censoring opinions it's over. Same with blaming Armbian being responsible for DietPi not fixing 'high priority' bugs in time: https://github.com/Fourdee/DietPi/issues/312#issuecomment-253204102

 

Sorry, if it's about preventing access to a sysfs node /proc/sunxi_debug/sunxi_debug then simply do it: chmod 000 /proc/sunxi_debug/sunxi_debug (and you're already done. If you lack the skills to build an OS image from scratch then provide a fix for your users and don't blame others providing you with a build system for your requirements you can't cope with due to your various special requirements)

 

Anyway: I don't support people deleting stuff I write (any more). Fortunately for DietPi users other Armbian devs handle this differently so DietPi users can still rely on a solid foundation for their distro of choice. The collection of links above is just necessary for the commit message when I'll remove the unsafe and absolutely useless code that has been submitted recently to Armbian in a few days (since there's no excuse to weaken default Armbian security)

[zador.blood.stained]

Nah, I said that the whole 'issue' wasn't that much of an issue (especially when using a distro that is designed to be a single-user system where everything runs with UID==0 like DietPi). And that puzzled me -- why do DietPi users who use a distro that is designed to be 'root only' fear 'root exploits'? Was just for my personal understanding and to get stuff publicly documented as it is now.

Because even if doesn't make any difference for processes started as logged in user, there are many services (mostly of "server" type) that run from special restricted accounts, and there privileges escalation is still a consideration.

 

Anyway, let's end this discussion for now, at least until we have to deal with new kernel sources for other SoC that may have this debug "feature". 

[tkaiser]

Because even if doesn't make any difference for processes started as logged in user, there are many services (mostly of "server" type) that run from special restricted accounts, and there privileges escalation is still a consideration.

Sure but that doesn't help that much when the whole distro is constructed around a 'everything runs as root' principle anyway. DietPi stores sensitive information in world-readable files (Wi-Fi credentials in /etc/network/interfaces for example) so privileges separation won't work there as it's supposed to anyway. And while that's just a problem for DietPi users I really hate when such 'design decisions' arrive at Armbian.

 

But you're right, let's stop this useless discussion, get rid of dangerous code soon and (note to myself) the next time we provide such a security advisory like this we'll provide the simple workarounds for users of other distros also immediately (to fix laughable stuff like rootmydevice a 'chmod 000' is enough, no need to waste days switching to another distro as foundation)

[zador.blood.stained]

Sure but that doesn't help that much when the whole distro is constructed around a 'everything runs as root' principle anyway. DietPi stores sensitive information in world-readable files (Wi-Fi credentials in /etc/network/interfaces for example) so privileges separation won't work there as it's supposed to anyway. And while that's just a problem for DietPi users I really hate when such 'design decisions' arrive at Armbian.

Even though it's a bit off-topic, using PSK key from wpa_passphrase still protects original passphrase (keep in mind this still was "recommended" by layout of our default interfaces file before accepting @Fourdee's PR), and recovering deleted file /boot/armbian_first_run.txt requires root (or "disk" group) privileges to even read block device:

root@odroidc2:~# ls -la /dev/mmc*
brw-rw---- 1 root disk 179, 0 Oct 13 00:39 /dev/mmcblk0
brw-rw---- 1 root disk 179, 1 Oct 13 00:39 /dev/mmcblk0p1