How Did Apple Screw Up Their Security?

 Computing, Security  No Responses »
Nov 292017
 

If you have not already heard about it, Apple made a mindbogglingly stupid mistake with the latest release of macOS (previously known as OSX), leaving their users open to an incredibly easy exploit that would give anyone full access over an Apple in their hands. Or in some cases, remotely.

The externally visible effect of the vulnerability is that a standard Unix account (root) that was supposed to be disabled was left with a blank password. Apple uses a very common Unix security mechanism that means the root account is unnecessary as an ordinary account (i.e. nobody logs in as root), although the account has to exist so that legitimate privilege escalation works.

As an alternative, Apple uses sudo (and graphical equivalents) so that members of a certain group can run commands as root. Nothing wrong with that.

To keep things safe, Apple disabled the root account and because the account was disabled, left the password blank.

It turns out that the vulnerability was caused by a bug in Apple’s authentication system which resulted in blank passwords being reset and the account enabled. But it is more complicated than that; Apple made a number of mistakes :-

  1. The bug in the authentication system. Of course no software is bug-free, but bugs are still mistakes. Of course because no software is bug-free, it makes sense to take extra precautions to avoid bugs causing a cascade of problems.
  2. The root password should have been set to a random value to prevent access if the account was accidentally enabled.
  3. Apple’s test suite which hopefully they use to verify that new releases don’t contain previously identified bugs should also check for this vulnerability.

Although the precise details don’t matter as it’s the principle of defence in depth.

Hemisphere and Curves

Linux Logical Volumes Not “Active” ?

 Linux, Working Notes  No Responses »
Aug 202013
 

Every so often I come across an old Linux box that doesn’t take kindly to being rebooted. Without console access, it is hard to see what is going on, but the Linux kernel gets stuck trying to mount the root file system. There are many possible fixes for this, but they all have one thing in common … a work-around has to be performed to get the box up and running.

The console gets stuck in a “mini-root” environment loaded when the initrd image is loaded and before the real root file system is mounted which means a lot of commands are not available, but lvm should be available. First of all, run lvm lvscan to get a list of the logical volumes that need activating :-

(initramfs) lvm lvscan
  inactive          '/dev/sys/root' [332.00 MiB] inherit
  inactive          '/dev/sys/usr' [8.38 GiB] inherit
  inactive          '/dev/sys/var' [2.79 GiB] inherit
  inactive          '/dev/sys/swap_1' [7.05 GiB] inherit
  inactive          '/dev/sys/tmp' [380.00 MiB] inherit
  inactive          '/dev/sys/home' [16.00 GiB] inherit
  inactive          '/dev/sys/opt' [24.00 GiB] inherit

For each volume group (the second column, middle word), run: lvm lvchange -ay ${volume-group-name}. In the case of my example :-

(initramfs) lvm vgchange -ay /dev/sys
  7 logical volume(s) in volume group "sys" now active

At which point you should be able to press ^D (or enter exit) to continue the boot process.

A slighter better work-around involves changing the Grub configuration to add a delay to the kernel parameters. This sections assumes that you are not using Grub Legacy!

Start by editing /etc/default/grub and changing the variable GRUB_CMDLINE_LINUX to include “rootdelay=20” :-

GRUB_CMDLINE_LINUX='console=tty0 console=ttyS0,19200n8 rootdelay=20'

Finalise by running update-grub. This adds a 20s delay to the boot process so is hardly an ideal solution.