Dietpi: OPi | Security exploit

[keiser1080]

Hi,

there is a security issue on loboris image.

more info there http://forum.armbian.com/index.php/topic/1108-security-alert-for-allwinner-sun8i-h3a83th8/

[Fourdee]

@keiser1080 :+1:

Thanks for letting us know.
I'll look for a resolution. Whether we compile our own kernel, or replace with a modified ARMbian 2 partition image, not sure yet.

[keiser1080]

Check wich the Guy from armbian, the only image patched.
There are no news from loboris for a longtime.
Maybe the switch to armbian is a gold idea.

[pepadew]

@Fourdee
i like the idea of e new kernel . possibly newer then 3.4?
im just poking my head arround and just got a pi so im new to compiling a safe kernel that wil work.

[Fourdee]

I've built the image using ARMbian build tools (hats off to those guys, simply excellent), which now supports an option to create an additional FAT partition at the start. I think the last time I tried this, that option wasn't available.

@pepadew
For DietPi, we will stick with 3.4 for stability. I also tested the kernel against the exploit:

root@orangepih3:~# echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug
-bash: /proc/sunxi_debug/sunxi_debug: No such file or directory

I just need to wrap up the image, get DietPi setup, run tests, should be available in the next day or two.

[pepadew]

@Fourdee what do i have to learn in order to build my own kali linux based on the sunxi 3.4?
im a novice that is pushed towards this for now, also it will be a good learning curve for me i suppose.
the 3.4 from loboris was not safe to use
but the 3.4 lagacy from sunxi is safe to use?
what do i need to do in order to debug this exploit?

[Fourdee]

@pepadew

what do i have to learn in order to build my own kali linux based on the sunxi 3.4?

No idea. I'd suggest you do some research on the ARMbian building tool to build a base image (with a distro of your choosing) and work from there: https://github.com/igorpecovnik/lib.

but the 3.4 lagacy from sunxi is safe to use?

With ARMbian building tools, it appears they patched this exploit: https://github.com/Fourdee/DietPi/issues/312#issuecomment-216839207
ARMbian commit: https://github.com/igorpecovnik/lib/commit/7a5aeda32d20a74b0ae5214828fe75e676cdf82b

what do i need to do in order to debug this exploit?

Test it with echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug as per the ARMbian post http://forum.armbian.com/index.php/topic/1108-security-alert-for-allwinner-sun8i-h3a83th8/

[Fourdee]

Having some issues with the DietPi image. Consecutive soft reboots work fine, but a hard power cycle seems to prevent it from booting.

I'am also unable to debug this as my OPi PC HDMI output is completely dead.

Can anyone run the test image and report back with any onscreen information?

I'd be grateful : http://dietpi.com/downloads/testing/DietPi_v117_OrangePi-PC-(Jessie).7z

[pepadew]

i just burnt it to micro sd, but im not getting any output on hdmi (opi pc).
tried fiddling with config, but no succes

[Fourdee]

@pepadew Thanks :+1:

I'll make another.

[alerinoreis]

reburning img to microsd is mandatory to fix the exploit?
thanks,

[keiser1080]

I will try to check tomorow
Le 4 mai 2016 7:12 PM, "Dan" [email protected] a écrit :

Having some issues with the DietPi image. Consecutive reboots work fine,
but a hard power cycle seems to prevent it from booting.

I'am also unable to debug this as my OPi PC HDMI output is completely
dead.
Can anyone run the test image and report back with any onscreen
information? I'd be grateful :
http://dietpi.com/downloads/testing/DietPi_v117_OrangePi-PC-(Jessie).7z

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Fourdee/DietPi/issues/312#issuecomment-216935306

[Fourdee]

Think it might be a filesystem corruption. After writing the ARMbian image I compiled, all I do is:

• Copy dietpi to /boot/dietpi
• Poweron
• After going through the initial ARMbian setup and creating an account (dietpi):

passwd #set to dietpi as root@
userdel -f dietpi
cat << _EOF_ > /etc/apt/sources.list
deb http://ftp.debian.org/debian jessie main contrib non-free
deb http://ftp.debian.org/debian jessie-updates main contrib non-free
deb http://security.debian.org jessie/updates main contrib non-free
deb http://ftp.debian.org/debian jessie-backports main contrib non-free
_EOF_
apt-get clean
apt-get update

After a hard power cycle wont boot. But soft reboots are fine.

[Fourdee]

note to self:

• Try ARMbian build with BOOTSIZE="64" as the only changed setting.
• Run same tests as: https://github.com/Fourdee/DietPi/issues/312#issuecomment-216958785
• Verify if adding files to /boot/ affects the issue.

[Fourdee]

root@orangepih3:~# systemctl status firstrun.service -l
● firstrun.service - LSB: PLEASE BE PATIENT AND DO NOT INTERRUPT THE FIRST REBOOT
   Loaded: loaded (/etc/init.d/firstrun)
   Active: failed (Result: exit-code) since Wed 2016-05-04 15:50:46 BST; 1 day 21h ago

May 04 15:50:41 orangepih3 firstrun[512]: Re-reading the partition table failed.: Device or resource busy
May 04 15:50:46 orangepih3 firstrun[512]: ln: failed to create symbolic link ‘/boot/script.bin’: Operation not permitted
May 04 15:50:46 orangepih3 systemd[1]: firstrun.service: control process exited, code=exited status=1
May 04 15:50:46 orangepih3 systemd[1]: Failed to start LSB: PLEASE BE PATIENT AND DO NOT INTERRUPT THE FIRST REBOOT.
May 04 15:50:46 orangepih3 systemd[1]: Unit firstrun.service entered failed state.

No symlinks on FAT: https://github.com/igorpecovnik/lib/blob/master/scripts/firstrun#L140

Partitioning fails, does not detect 2 partitions correctly? breaks filesystem?: https://github.com/igorpecovnik/lib/blob/master/scripts/firstrun#L177

root@orangepih3:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p2  826M  716M   94M  89% /
udev             10M     0   10M   0% /dev
tmpfs           201M  4.5M  196M   3% /run
tmpfs           501M     0  501M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           501M     0  501M   0% /sys/fs/cgroup
tmpfs           501M  4.0K  501M   1% /tmp
/dev/mmcblk0p1   64M   16M   49M  25% /boot
tmpfs           101M     0  101M   0% /run/user/0

Partition resize successful after 2nd boot, but firstrun.service still reports same error as above.
Hard power cycle at this point = won't boot.

Another test:

• Write image.
• Disabled do_expand_rootfs from /etc/init.d/firstrun
• Disabled ln -sf /boot/bin/orangepipc.bin /boot/script.bin from /etc/init.d/firstrun
• Powered on device, few apt removals
• Hard power cycle

Running fine.

• cp /boot/bin/orangepipc.bin /boot/script.bin
• Hard power cycle

Running fine.

Issue = failed firstrun service with functiondo_expand_rootfs corrupting file system on a 2 partition ARMbian build tool generated image.

[Fourdee]

[Fourdee]

@keiser1080 @pepadew @alerinoreis

New image has been created, built with ARMbian. I'd appricate it any of you could test the image on your systems: http://dietpi.com/downloads/testing/DietPi_OrangePi-PC-(Jessie).7z

[Fourdee]

To confirm the exploit is not available in the new image:

• DietPi_v115_OrangePi-PC-(Jessie) (Loboris) | Exploit active

root@DietPi:~# echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug
root@DietPi:~#

• DietPi_v117_OrangePi-PC-(Jessie) (ARMbian) | Exploit disabled

root@DietPi:~# echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug
-bash: /proc/sunxi_debug/sunxi_debug: No such file or directory

[Fourdee]

Created post on OPi forum: http://www.orangepi.org/orangepibbsen/forum.php?mod=redirect&goto=findpost&ptid=662&pid=12541&fromuid=185718

[Fourdee]

DietPi_v117_OrangePi-PC-(Jessie) (ARMbian) is now the active download. http://dietpi.com/downloads/images/

Marking this as closed.

[keiser1080]

As usual very fast support.
Thanks for your work, i will post an announcement on the orange pi facebook group

[keiser1080]

@Thomas

This issue is closed.
Dietpie use no more loboris.
Dietpie use armbian.

Le 11 oct. 2016 7:02 PM, "Thomas Kaiser" [email protected] a
écrit :

@keiser1080 https://github.com/keiser1080

there is a security issue on loboris image.

Why do you feel affected by this when using DietPi? Did you create an
unprivileged user account or are you running everything as root anyway?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Fourdee/DietPi/issues/312#issuecomment-252979067, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABqDzdxizSrXXckJPsvtSfMWA8IcPNL4ks5qy8EqgaJpZM4IVmOT
.

[keiser1080]

I better understand. I have no time to play with my orange pi or to test
anything.
But i remembrer the first thing i do when i have install dietpie, is to
create my user, and i think i have tested using my user and i can't promot
to root using the bug after the update.

Le 11 oct. 2016 8:43 PM, "Thomas Kaiser" [email protected] a
écrit :

@keiser1080 https://github.com/keiser1080

This issue is closed.

I know, but nothing has been fixed, quite the opposite is true :)

This is somewhat weird:

root@DietPi:~# echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug
root@DietPi:~#

In DietPi where everything is supposed to happen as root anyway a local
privileges escalation that ends up with the user becoming root (_still_
being root in reality) shouldn't matter that much, right? Especially this
demonstration above is strange. How should root become even more root?

And the other problem is: even if you create unprivileged user accounts
and think by implementing privileges separation security would improve
you're lost since DietPi isn't designed that way. It's a single user system
where everything should happen as root (otherwise stuff like Wi-Fi
credentials in world-readable files like /etc/network/interfaces would
become a problem -- DietPi is not designed for unprivileged user accounts
and therefore the whole rootmydevice issue is neither a real problem nor
fixable here -- hey, you're root anyway :) )

BTW: the way DietPi is designed is quite ok, but users should be aware of
the security level they 'enjoy' when a distro chooses that everything (even
browsing the web) should happen as root.

So again: why did you think the rootmydevice issue would affect DietPi?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Fourdee/DietPi/issues/312#issuecomment-253007151, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABqDzbLI5YENIJhpbxDKb1rfrQOkllKZks5qy9jGgaJpZM4IVmOT
.

[ThomasKaiser]

@keiser1080

I have no time to play with my orange pi or to test anything.

So you trust in default security settings of the distro you chose?

the first thing i do when i have install dietpie, is to create my user

But is this supposed to have any real effect on a distro that relies on 'everything should be done as root' anyway? DietPi stores sensitive information in world-readable files by default (since the main dev might not be able to imagine that not everyone wants to do his daily work as root?). Does privileges separation works when the OS does not care about exactly that?

@Fourdee BTW: you do a great job here publicly documenting how you think about this issue. You can delete my comment again (would then be the fifth comment today) and it won't help. This 'discussion' (me asking questions, you censoring everything away) happens in the open. :)

@Fourdee BTW: It took DietPi 9 days between taking notice and providing a fix. If I were you the next time I would focus on security first. Letting your users or a DietPi mechanism execute this

chmod 000 /proc/sunxi_debug/sunxi_debug

(and putting that to /etc/rc.local for example) would've protected your users already and could've been implemented within hours (also called 'security first' approach)

[keiser1080]

Every distro have avantages & disavnetage.
Dietpie is not fucused on the security.
I like dietpie because it is light, and it come wich a lot of usefull tools.
I have a lot of respect for the work done by fourdee.
I know it's a lot of time for a single men.

I think the security is not an issue you can create a non privilegied user,
But again you are free to chose another distri more focused on the security.
I don't know if there is a distro focused on security for the orange pi.

Le 11 oct. 2016 11:17 PM, "Thomas Kaiser" [email protected] a
écrit :

@keiser1080 https://github.com/keiser1080

I have no time to play with my orange pi or to test anything.

So you trust in default security settings of the distro you chose?

the first thing i do when i have install dietpie, is to create my user

But is this supposed to have any real effect on a distro that relies on
'everything should be done as root' anyway? DietPi stores sensitive
information in world-readable files by default (since the main dev might
not be able to imagine that not everyone wants to do his daily work as
root?). Does privileges separation works when the OS does not care about
exactly that?

@Fourdee https://github.com/Fourdee BTW: you do a great job here
publicly documenting how you think about this issue. You can delete my
comment again (would then be the fifth comment today) and it won't help.
This 'discussion' (me asking questions, you censoring everything away)
happens in the open. :)

@Fourdee https://github.com/Fourdee BTW: It took DietPi 9 days between
taking notice and providing a fix. If I were you the next time I would
focus on security first. Letting your users or a DietPi mechanism execute
this

chmod 000 /proc/sunxi_debug/sunxi_debug

(and putting that to /etc/rc.local for example) would've protected your
users already and could've been implemented within hours (also called
'security first' approach)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Fourdee/DietPi/issues/312#issuecomment-253049225, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABqDzQ6wzR_ehy7DH5N6McUL5sawwshRks5qy_zggaJpZM4IVmOT
.

[ThomasKaiser]

Every distro have avantages & disavnetage.

Absolument! But it's important to know them.

You know that you started this issue here with a link to my forum post? At the time we (Armbian team) were pretty confident that this issue is not that much of an issue at all (at least for the average user). We have the infrastructure to fix such stuff within hours but if that would've been not the case... we would've provided a work-around since it's more or less a non-issue for the average user (especially when using DietPi)

But since I had to scratch my head a few days ago regarding 'security best practices' (affecting Armbian and not related to DietPi at all!) I became curious how DietPi handles this and how DietPi users expect how things should work (just to understand other human beings). So thank you for the feedback even if it got interrupted by multiple occurences of censorship.

BTW: I also appreciate the work done by David and I already looked into using a few enhancements with Armbian (power management for crappy Wi-Fi dongles comes to my mind) but I fear we'll never agree about security in general (which is ok -- different projects, different goals, but at least users should be aware of)

[keiser1080]

Yes i remembrer you.
You are very active in armbian forum.

I dont think it's censor, maybe is not the best place to talk about this.
This discutions is more suitable on a forum.

Le 12 oct. 2016 12:13 AM, "Thomas Kaiser" [email protected] a
écrit :

Every distro have avantages & disavnetage.

Absolument! But it's important to know them.

You know that you started this issue here with a link to my forum post? At
the time we (Armbian team) were pretty confident that this issue is not
that much of an issue at all (at least for the average user). We have the
infrastructure to fix such stuff within hours but if that would've been not
the case... we would've provided a work-around since it's more or less a
non-issue for the average user (especially when using DietPi)

But since I had to scratch my head a few days ago regarding 'security best
practices' (affecting Armbian and not related to DietPi at all!) I became
curious how DietPi handles this and how DietPi users expect how things
should work (just to understand other human beings). So thank you for the
feedback even if it got interrupted by multiple occurences of censorship.

BTW: I also appreciate the work done by David and I already looked into
using a few enhancements with Armbian (power management for crappy Wi-Fi
dongles comes to my mind) but I fear we'll never agree about security in
general (which is ok -- different projects, different goals, but at least
users should be aware of)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Fourdee/DietPi/issues/312#issuecomment-253062766, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABqDzYQJhuIA3uWLUh8oPbQlxPGyzhV6ks5qzAoQgaJpZM4IVmOT
.

[Fourdee]

@ThomasKaiser

(and putting that to /etc/rc.local for example) would've protected your users already and could've been implemented within hours (also called 'security first' approach)

Not sure you are aware, but this ticket has been closed for over 5 months. If you had an issue with the way this ticket was handled, why didn't you make that clear when the ticket was active?

When I was taking time out of the DietPi project to help contribute to ARMbian source code, you continually raised comments of "not best security practice" in relation to DietPi. I asked you to find any security flaws in DietPi so we can investigate your claims:

• https://github.com/igorpecovnik/lib/issues/488#issuecomment-251753485
• 

In your reply, you clearly stated this was a waste of your time:

• https://github.com/igorpecovnik/lib/issues/488#issuecomment-251794370
• 

@Fourdee BTW: It took DietPi 9 days between taking notice and providing a fix. If I were you the next time I would focus on security first.

At least a few days of the above can be pointed at bugs in ARMbian, failing to build the image. During this time, I reported the bug to ARMbian: https://github.com/igorpecovnik/lib/issues/290#issuecomment-223809674
It took ARMbian 1 month to resolve this bug.
I'd suggest you look at issues closer to home.

@ThomasKaiser If you have an issue you would like to raise with DietPi:

• Please create a new git ticket.
• Be specific and get to the point.
• Include proof and tests that can be replicated, to backup your claims.

We respect our users at DietPi. So, In the mean time, I will continue to delete all posts you make that are simply "here say" and pointless trash talk aimed at our users.