• Announcements

    • 1. Check power supply, check SD card and check other people experiences

      Power supply issues are one of the three biggest issues you'll face when starting with Single Board Computers (SBCs). SD card issues, whether fake or faulty, are another and issues resulting from poor board design is the other common issues you can encounter.   Power supply issues can be tricky. You might have a noisy power supply that works with one board because it has extra filtering, but won't work with another. Or you're using that cheap phone charger because your board has a microUSB connector, and it is either erratic, or doesn't start up, or even becomes the cause of some SD card issues.    Some tips to avoid the most common causes of problems reported:   Don't power via micro USB  - unless you have optimised your setup for low power requirements. Micro USB is great for mobile phones because they are simply charging a battery. It's bad for SBCs. Yes, it does work for a lot of people, but it also causes more problems and headaches over time than it is worth, unless you know exactly what you are doing. If you have a barrel jack power connector on your SBC, use it instead! If there is an option for powering via header connections, use that option!
        Don't use mobile phone chargers. They might be convenient and cheap, but this is because they are meant for charging phones, not powering your SBC which has particular power requirements.
        When you are evaluating a power supply, make sure you run some stress tests on your system to ensure that it will not cause issues down the path.   (Micro) SD card issues can be sneaky. They might appear right at the start causing strange boot and login errors, or they might cause problems over time. It is best to run a test on any new SD card you use, to ensure that it really is what it is, and to ensure that isn't faulty. Armbian provides you a simple way to do this   --   armbianmonitor -c /path/to/device/to/test  
    • 2. Make sure to collect and provide all necessary information

      We can only help if you provide quality information for us to work with. All stable images from the download section are tested, most stable upgrades are tested and we have tens of thousands of users. Even with regular and extensive testings, bugs sometimes do slip through. This is a voluntary support service and is unrelated to board makers, and is not obligated to provide you any answers. Repeated asking the same questions because you're not happy with the answers will result in you being ignored.

      Before you post a question, use the forum search as someone else might have already had the same problem and resolved it. And make sure you've read the Armbian documentation. If you still haven't found an answer, make sure you include the following in your post:   1. Logs when you can boot the board: armbianmonitor -u (paste URL to your forum post)   2. If your board does not boot, provide a log from serial console or at least make a picture, where it stops.   3. Describe the problem the best you can and provide all necessary info that we can reproduce the problem. We are not clairvoyant or mind readers. Please describe your setup as best as possible so we know what your operating environment is like.     We will not help in cases you are not using stable official Armbian builds, you have a problem with 3rd party hardware or reported problem would not be able to reproduced.

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

25 posts in this topic

Recommended Posts

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)
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)
Igor, wildcat_paris and sooperior like this

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

@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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

Titanic might float again first, I suspect.

Share this post


Link to post
Share on other sites

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! 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

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.

rodolfo likes this

Share this post


Link to post
Share on other sites

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) 

Share this post


Link to post
Share on other sites

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

 

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.

Share this post


Link to post
Share on other sites

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.

Tom_Neverwinter likes this

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

0

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.