S09E39 – Error Establishing Database Connection

24th November 2016 Samantha

It’s Season Nine Episode Thirty-Nine of Ubuntu AU! Alan Pope, Mark Johnson, Martin Wimpress and Dan Kermac are connected and speaking to your brain.

Podcast: Play in new window | Download

We are four once more, thank you Australia!

In this week’s show:

That’s all for this week! If there’s a topic you’d like us to discuss, or you have any feedback on previous shows, please send your comments and suggestions to [email protected] or Tweet us or Comment on our Facebook page or comment on our Google+ page or comment on our sub-Reddit.

4 Comments » for S09E39 – Error Establishing Database Connection
  1. Daniel says:
    28th November 2016 at 13:26

    I’m really disappointed in the LUKS “vulnerability” discussion. Did you all forget to mention how the encryption itself wasn’t compromised and a shell at boot really does nothing but modify the /boot contents and other partitions that are not encrypted (and this could be accomplished anyway by any liveCD???)? I’m assuming that since 98% of Linux machines out there are not using “secure boot” in the uefi, I’m curious how /boot safeguards against tampering like “kernel replacement from a 3rd party”……is there checksum on /boot upon successful LUKS entry into the system? Last time I heard, this was still a “thing” back in 2013 and the way you’d mitigate it was by storing your entire /boot partition and keys on a usb drive and plain dm-crypt everything else on the machine. I would like Martin to explain this is full detail.

  2. daniel66666 says:
    28th November 2016 at 13:57

    *in

  3. Martin Wimpress says:
    29th November 2016 at 11:17

    As explained in the CVE-2016-4484:

    An attacker with access to the console of the computer and with the ability to reboot the computer can launch a shell (with root permissions) when he/she is prompted for the password to unlock the system partition. The shell is executed in the initrd environment. Obviously, the system partition is encrypted and it is not possible to decrypt it (AFAWK). But other partitions may be not encrypted, and so accessible. Just to mention some exploitation strategies:

    • Elevation of privilege: Since the boot partition is typically not encrypted:
      • It can be used to store an executable file with the bit SetUID enabled. Which can later be used to escalate privileges by a local user.
      • If the boot is not secured, then it would be possible to replace the kernel and the initrd image.
    • Information disclosure: It is possible to access all the disks. Although the system partition is encrypted it can be copied to an external device, where it can be later be brute forced. Obviously, it is possible to access to non-encrypted information in other devices.
    • Denial of service: The attacker can delete the information on all the disks.

    So that outlines the impact. As to mitigation, if someone has physical access to your server then all bets are off, there is no adequate mitigation. The information security CIA triad (confidentiality, integrity and availability) can no longer be assured. Locks and encryption do not prevent access to anything, they merely delay access.

  4. daniel66666 says:
    29th November 2016 at 12:24

    Again, I fail to see the “vulnerability” here. All 3 of those bullet points could simply be accomplished with a root shell from any liveCD, no? A PoC was demonstrated of kernel replacement on /boot over 5 years ago: https://twopointfouristan.wordpress.com/2011/04/17/pwning-past-whole-disk-encryption/