Debian jessie image 1.0 released for Bubba|2 / B3

Discuss development on Bubba
Gordon
Posts: 1311
Joined: 10 Aug 2011, 03:18

Re: Debian jessie image 1.0 released for Bubba|2 / B3

Post by Gordon » 12 Dec 2015, 15:38

Uncertain how to interpret that. From the links you provided it seems a hacker would need to get to the B3 multiple times, with you accessing it in between and entering the password which could then be read in plain text by the returning hacker.

It doesn't state though how strong the key itself is and if someone who stole your B3 could get to the encrypted content in some fairly simple way. As in with more ease than it would be to get to that data through any of the B3's sharing methods while it is still running. If there is no analytical method to crack it and it would thus require brute force, then this type of encryption would still be good.

Stryker
Posts: 55
Joined: 17 Oct 2013, 11:03

Re: Debian jessie image 1.0 released for Bubba|2 / B3

Post by Stryker » 12 Dec 2015, 16:09

I am more worried about my B3 being lifted and its encryption broken due to it being a 128Bit cipher since that is the maximum the hardware-accelerator is able to perform.

But regarding my dump-tarball-installation:
I currently have issues due to permissions not being set correctly.
Does your original payload-tarball preserve the permissions and ownership or does the installer set them manually?
Right now everything on my dev-b3 has ownership excito:excito except for /proc, /dev etc.
Also I cannot su, setgid Operation not permitted.
I figure both issues are intertwined.

Maybe I should just run the installer without wiping.
You mentioned it being able to just take sda1 as the root partition and whatever swap-partition is available.

Gordon
Posts: 1311
Joined: 10 Aug 2011, 03:18

Re: Debian jessie image 1.0 released for Bubba|2 / B3

Post by Gordon » 12 Dec 2015, 16:43

I don't think that's what I said. That is: I did not mean to imply that.

In detail: the u-boot bootloader in flash is configured to load the kernel from /dev/sda1 and amongst the parameters it passes to that kernel is that the root partition is at /dev/sda1 as well. There are three options here:
  1. you edit the u-boot environment and change the parameters to pass to the kernel
  2. you ignore those parameters by hardcoding a different command line in the kernel itself
  3. you patch the kernel to read the actual parameters from some other location
The options that you will be able to use mainly depend on which distro you start off with and whether you are willing to build your own kernel.

With regards to swap: this is something you point to in /etc/fstab. I do advise that you do not keep the original disk layout and move swap as close to the front of the disk as possible. There's no need to make a fuzz about a gigabyte more or less because there are a\other bottlenecks, but if you can get it within the first 25% of the total disk space you will get significantly better performance.

sakaki
Posts: 171
Joined: 15 Aug 2014, 11:20

Re: Debian jessie image 1.0 released for Bubba|2 / B3

Post by sakaki » 13 Dec 2015, 14:11

Warning - long and somewhat off-topic post follows ^-^
Gordon wrote:Uncertain how to interpret that. From the links you provided it seems a hacker would need to get to the B3 multiple times, with you accessing it in between and entering the password which could then be read in plain text by the returning hacker.
That's not quite it. This issue is that CBC mode enables a hacker with knowledge of the contents and location of at least some plaintext system files on your HDD (not unreasonable if a standard install process has been followed post LUKS format), and access to your (encrypted) HDD, to overwrite appropriate ciphertext blocks on that device to inject shellcode, which then executes during the boot process at root privilege.

The attack is possible because CBC mode encrypts like this:
Image
CBC adds the xor step to address the major problem with ECB (electronic codebook) mode, in which identical plaintext blocks (a block = 128 bits in AES, regardless of key length) appear as identical ciphertext blocks, allowing e.g. the encrypted disk to be scanned for the 'fingerprints' of certain target files:

ImageImage
ECB mode: Encrypted, But Still Identifiable

However, although CBC mode fixes this issue, it introduces another (the malleability vulnerability). It decrypts blocks as follows:
Image

As such, if an attacker knows the (true) plaintext of block n on the HDD (128 bits/16 bytes from an init script, for example), she can overwrite the ciphertext of block n-1, to force any desired text to come out as the result of decrypting block n. She doesn't need to know the encryption key to do this.

To see how this exploit works, let:
Cn -1 = (original) ciphertext of block n-1
Cn = (original) ciphertext of block n
Pn = known (original) plaintext of block n
Dn = result of decrypting Cn with (unknown to attacker) key K, prior to xor
Sn = desired (128 bit) shellcode for block n
+ = xor

Then, because Pn = Cn-1 + Dn, if we replace Cn-1 with Sn + Cn-1 + Pn, the decoder will dutifully return:
(Sn + Cn-1 + Pn) + Dn
= Sn + Pn + (Cn-1 + Dn)
= Sn + Pn + Pn
= Sn, and the fix is in.

Of course, this means that the decrypted text of block n-1 will be garbage. However, that may not matter; for example, if block n-1 contains comment text in a script file.

As such, it is now generally recommended not to use CBC mode for disk encryption, but to use either a counter mode or (most commonly seen) Xor-encrypt-xor tweaked codebook mode with ciphertext stealing (XTS), which encrypts like this:
Image

OK, so, if XTS mode is chosen, then you still need to fix on the block cipher, key length and hash (used in the LUKS header).

Reasonable choices for the block cipher include AES/Rijndael and (my own personal favourite) Serpent.

As to key length, a key length of 128 bits (for AES or Serpent) should be sufficient against any feasible brute force attack using conventional hardware, barring any catastrophic break in the underlying cryptosystem. However, if usable quantum computers are really on the way, then be aware that Grover's algorithm will let these essentially halve the number of bits of effective security - so a 128 bit key will become a 64 bit key (for a symmetric cipher). As such, a more conservative approach (and that now advocated by the NSA) is to use a 256 bit key. (Of course, the bigger problem with quantum computing is for public key cryptography, most variants of which (via Shor's algorithm) it will effectively render useless overnight... but that's another story.)

Whatever key length you choose, be aware that if you use XTS mode this utilizes two different keys internally, usually created by splitting your original key in half. So, to get e.g. 256 bits of protection, you actually need to specify a 2 * 256 bits = 512 bits key.

The last piece of the puzzle is the hash used by LUKS during key generation. Any of the SHA-2 family (e.g. SHA512 or SHA256) would be sensible choices here.

Conclusion

Putting this together, a relatively paranoid cryptsetup might be:

Code: Select all

# cryptsetup -v --cipher serpent-xts-plain64 --key-size 512 --hash sha512 --use-random --verify-passphrase --iter-time 2000 luksFormat <device>
for Serpent, or

Code: Select all

# cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 --use-random --verify-passphrase --iter-time 2000 luksFormat <device>
for AES.

We use the former personally on all our home B3s and have never experienced any disk performance issues (but YMMV, if your processor is particularly loaded most of the time with other tasks, for example). Of course, follow all local laws etc. when setting up an encrypted system.

I have some other comments about LUKS setup in my Gentoo Wiki setup guide here (this is oriented towards users setting up a PC, but there are some useful references etc. in the text).

Finally, as with all things crypto, it is best to keep a sense of perspective... if a TLA really wanted your data (credit: xkcd):

Image
^-^

Best, sakaki

PS any reference to 'text' in the above is purely in the cryptographic sense and does not imply e.g. ASCII - it could be any binary payload e.g. machine code.
Last edited by sakaki on 13 Dec 2015, 14:26, edited 1 time in total.

MouettE
Site admin
Posts: 248
Joined: 06 Oct 2011, 19:45

Re: Debian jessie image 1.0 released for Bubba|2 / B3

Post by MouettE » 13 Dec 2015, 14:26

sakaki wrote:Warning - long and somewhat off-topic post follows ^-^
As always you never cease to amaze me :shock:
Stryker wrote: I currently have issues due to permissions not being set correctly.
Does your original payload-tarball preserve the permissions and ownership or does the installer set them manually?
Right now everything on my dev-b3 has ownership excito:excito except for /proc, /dev etc.
Sounds like you extracted the tarball as a regular user. The permissions and ownerships in the the tarball must be preserved while extracting (the installer does nothing else) so it must be done as root. That's probably why your ssh host keys where not generated on first boot.
Gordon wrote:Strange... I thought ssh generates those key files by itself if either one is missing. Quite sure it did on my system (did not have the ed25519 key when I transferred to Gentoo)
That's not exactly true. On most distribution the ssh server init script generates those keys if they are missing before running sshd ... except on debian. If the key are missing, sshd will start but any connection attempt will be denied. You have to reconfigure the ssh server package to generate those keys.
Gordon wrote:With regards to swap: this is something you point to in /etc/fstab
With systemd you do not need to specify the swap partition in fstab, it is automatically found and activated. That's why the jessie image can accomodate any swap partition on the disk as long as there is one.

Gordon
Posts: 1311
Joined: 10 Aug 2011, 03:18

Re: Debian jessie image 1.0 released for Bubba|2 / B3

Post by Gordon » 14 Dec 2015, 03:53

sakaki wrote:Warning - long and somewhat off-topic post follows ^-^
Thanks for explaining the vulnerability.

It does however kind of state the same. The hack does not open the lock, but allows you to be able to steal the key for it. Meaning that the key holder must be able to return to the machine AND not know that it was tampered with. Which brings us back to the original question that if the device was stolen how this code would withstand any actual cracking attempt, apart from guessing an easy password of course.

The thing to keep in mind here is that (if you think you need one at all) a bad lock is still better than no lock at all. And that this lock is the one that is supplied by the hardware. As the original poster stated himself, if you'd need to run the encryption protocol on the main CPU itself it would become very bad at serving its intended purposes.

MouettE wrote:With systemd you do not need to specify the swap partition in fstab, it is automatically found and activated. That's why the jessie image can accomodate any swap partition on the disk as long as there is one.
Ah. Didn't know about this version using systemd. That simplifies the task at hand, that one should move swap close to the front of the disk to get better performance out of the B3. 8)

Tweety
Posts: 7
Joined: 02 Jul 2013, 07:28

Re: Debian jessie image 1.0 released for Bubba|2 / B3

Post by Tweety » 01 Feb 2016, 09:20

I'd just like to thank you MouttE for this image!

I have now a working B3 with Debian Jessie running Webmin and Transmission/DLNA/Samba/FTP servers like I wanted it too, with support for Java 8 to run a renamer for downloaded files before adding them to the library...

It took a little work to get all parts installed to my liking, and a few false starts where i fubar'ed something up and had to start over, but I got there in the end, and learned a whole lot...

Now, all that's left is to get LMS 7.9 compiled and running... Apparently it doesn't work with perl 5.20, and needs 5.18.0... Ho-hum...

Tweety
Posts: 7
Joined: 02 Jul 2013, 07:28

Re: Debian jessie image 1.0 released for Bubba|2 / B3

Post by Tweety » 13 Feb 2016, 07:41

I'll say it again... MouttE, thank you, thank you, thank you for your work... :D

After FUBAR'ing my install yet again, for what time in the order I don't know... :oops: As I was trying to mangle together scripts I barely understand, I got fed up restoring from scratch, and figured I'd give it a go to make my own payload...

Well... That worked even less well than trying to compile stuff from source, even if I followed your outlined steps... Imagine that... :roll:

So, I had an epiphany... Why reinvent the wheel, if you had already done it for me... :idea:

I did a fresh install on Jessie, uncompressed your payload, jailed it, and dumped on my needed packages for where I knew I had a stable and working setup, and my user credentials, and re-compressed it and stuck it back on the USB drive... :!: Tadaa, I now had a restore that saved me hours of waiting for package dependencies...

A few hours of trial and error to solve my install issues with each package that's been bugging me, and a couple days of stability testing in between, and I'm now on my third iteration, and getting close to the point where I can be back up and running a stable server in a matter of an hour or less, even when I get to courageous with my script mangling...

If I could figure out how to email you a big cake and some party balloons, I'd send them right now... :mrgreen:

mintz
Posts: 25
Joined: 31 Dec 2012, 08:03

Re: Debian jessie image 1.0 released for Bubba|2 / B3

Post by mintz » 07 Mar 2016, 05:39

This dist works great but I just cannot seem to get LogitechMediaServer to install. slimserver-vendor compiles but the binaries give this error:

Code: Select all

The following CPAN modules were found but cannot work with Logitech Media Server:
  Image::Scale:
Image::Scale object version 0.11 does not match bootstrap parameter 0.08 at /usr/lib/arm-linux-gnueabi/perl/5.20/DynaLoader.pm li
ne 210.
Compilation failed in require at (eval 92) line 1.
BEGIN failed--compilation aborted at (eval 92) line 1.
Can I just pull the binaries from one of the pre-built b3 images or is there any guide on how to install LMS properly?

Gordon
Posts: 1311
Joined: 10 Aug 2011, 03:18

Re: Debian jessie image 1.0 released for Bubba|2 / B3

Post by Gordon » 07 Mar 2016, 17:21

Ah yes. I had some issues getting that running myself. The problem with LMS is that it tries to be a stand-alone installation but it actually isn't. The additional problem is that you need all the platform dependent modules to match your CPU and they stopped shipping binaries for ARMv5 after perl 5.10. And then there is the one problem to rule them all that the LMS developers made their code depend on changes they requested to be integrated in existing modules but never actually were.

Essentially what you need to do is get rid of every element in [installpath]/CPAN that is also in [vendor-path]. You may take this a bit further to remove everything from CPAN that is in any other part of perl-path, except DBIx. You could investigate my LMS ebuild on github

A running 7.8.0 version (on perl 5.20.2) can be taken from the B3 Gentoo Live USB 1.7.0 SE. Of course, since you are running a different distro you will need to figure out the dependencies yourself.

mintz
Posts: 25
Joined: 31 Dec 2012, 08:03

Re: Debian jessie image 1.0 released for Bubba|2 / B3

Post by mintz » 07 Mar 2016, 21:43

I've never used ebuild before. Figure it has something to do with Gentoo, right? I'm a complete lost cause on it :p

Can you explain a bit more on the part of how to get rid of elements in CPAN? Is it just as simple as to delete the files and expect the build script to ignore them? And which files do I need to remove?

Gordon
Posts: 1311
Joined: 10 Aug 2011, 03:18

Re: Debian jessie image 1.0 released for Bubba|2 / B3

Post by Gordon » 08 Mar 2016, 06:42

I don't know what you got and what you built, so I can't really answer that

Ebuild is the Gentoo package manager. It allows redefining default actions (unpack, configure, compile and install) so you can add patches or manipulate the source in some other way and run specialized scripts before, during or after.

The ebuild I wrote will create a running version of LMS 7.8.0 (I'm not doing the unofficial beta 7.9). I have had it running with perl 5.18 and am now running it with perl 5.20. Points of interest:
  • src_unpack()
    I'm grabbing the noCPAN version of LMS because the other versions contain binaries that will not work on the B3. I'm grabbing the CPAN sources and a more recent version of Class::XSAccessor because the one included in the CPAN sources will not run with recent perl
  • src_prepare()
    There are five patches included here. I got these from previous existing projects. I am deleting Compress::Raw::Zlib module here, both in the CPAN source and the LMS folder. I also make some changes to the buildme.sh script that compiles the CPAN sources. In essence: I am skipping al components that the OS already provides as a package.
  • src_install()
    Here lms_clean_oldfiles() is called to remove all modules from the LMS CPAN folder for which duplicate/newer versions exist in the perl vendor_path. Obviously this assumes that all required perl modules are installed on the system (as enforced through the dependencies set by the ebuild). You may extend this by running the same action on the other perl include paths, but you must keep the DBIx folder and content in CPAN.
As said: a binary version is included on Sakaki's Gentoo Live USB 1.7.0 SE. You could copy /opt/logitechmediaserver right off it, but you will need to meet the dependencies to be able to run LMS. It is not a stand-alone version.

MrOpa
Posts: 2
Joined: 22 Mar 2016, 06:52

Re: Debian jessie image 1.0 released for Bubba|2 / B3

Post by MrOpa » 22 Mar 2016, 16:38

Ok so being encouraged by the success people had here and had use the standard B3 USB rescue stick on numerous occasions before I thought I would give this a go since squeezy support was dropped on Feb 29th. Everything seems to be fine when installing but then the issues start..

1) I have the same issue as beaufils with the networking. Tried changing the parameters but no good. Had to use DHCP.

2) I was suprised that the home folder was completely wiped even though I set wiped = false (anyone else should be aware of this). df command after install gives:

Code: Select all

Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/root       10190116 599544   9066288   7% /
devtmpfs          255476      0    255476   0% /dev
tmpfs             255564      0    255564   0% /dev/shm
tmpfs             255564   4384    251180   2% /run
tmpfs               5120      0      5120   0% /run/lock
tmpfs             255564      0    255564   0% /sys/fs/cgroup
So I am supposed to mount the sda2? Is that formatted completely after the install?

NOTE: I am not so worried about loosing data since I have everything backuped - I am just suprised that this was not just left alone and added post install?

Anyone else had these issues?

MouettE
Site admin
Posts: 248
Joined: 06 Oct 2011, 19:45

Re: Debian jessie image 1.0 released for Bubba|2 / B3

Post by MouettE » 23 Mar 2016, 11:23

Hello and thank you for your return.
MrOpa wrote:1) I have the same issue as beaufils with the networking. Tried changing the parameters but no good. Had to use DHCP.
I didn't have the time to look into that yet, I'll take a look.
MrOpa wrote:2) I was suprised that the home folder was completely wiped even though I set wiped = false (anyone else should be aware of this)
It would be very strange because I paid much attention on this part. All commands run by the installer are logged into the file install/install.log on the USB key. Can you post it so I can have a look ?
MrOpa wrote:So I am supposed to mount the sda2? Is that formatted completely after the install?
Yes. The installer won't do it for you you need to edit fstab according to the existing data partition you may have.

MrOpa
Posts: 2
Joined: 22 Mar 2016, 06:52

Re: Debian jessie image 1.0 released for Bubba|2 / B3

Post by MrOpa » 23 Mar 2016, 12:12

Hmm looking closer at this it is pretty obvious I don't know for sure what happened to the /home yet. My main problem seems to be that I can't mount it again (as you mentioned that has to be done afterwards).

Ah okey now I get it. I'll write things down here if it is not apparent for everyone (it wasn't for me)

When you use this installer it is a very clean debian system you get. The bubba system you had before used something called logica volumes which does not exist out of the box in the new one.

You need to install lvm2:

Code: Select all

sudo apt-get install lvm2
Activate the bubba volume:

Code: Select all

sudo vgchange -ay bubba
Mount it:

Code: Select all

sudo mount /dev/bubba/storage /home
Put this in /etc/fstab to make it permanent:

Code: Select all

/dev/mapper/bubba-storage       /home   ext3    defaults        0       2
Thank you for the help MouettE and sorry for the initial confused post :)

The networking was still an issue for me though. I will post the command when I get back to the USB stick

Post Reply