Re: CVE-2016-4484: - Cryptsetup Initrd root Shell

[Jason Cooper <osssecurity () lakedaemon net>]

Hi John,

On Wed, Nov 16, 2016 at 04:11:57PM +0000, John Haxby wrote:
> On 16/11/16 15:55, Jason Cooper wrote:
> > How does this differ from an attacker setting 'init=/bin/sh' on the
> > kernel command line?  Or, booting from attacker provided media?  Or, in
> > OS X, booting in single user mode?
> >
> > Your Discussion section at the end mentions facilities (GRUB passwords,
> > BIOS passwords, etc) for preventing this "Developer friendliness".  How
> > do you envision the installer enabling these while providing a failsafe
> > that an attacker can't exploit?
>
> If you set a grub password then the attacker cannot set init=/bin/sh on
> the kernel command line without knowing the grub password.   However,
> when the boot process prompts you for the encrypted volume password you
> can just hit enter until you eventually get a shell prompt.  Of course,
> the attacker needs to be able to see the console where the password is
> typed in ...

First, I'll clarify that I agree there is a bug in the initrd scripts
for decrypting a system volume.  Anything that doesn't fail in a
deterministic fashion is asking for trouble.

As for your scenario, as usual, it comes down to threat models.  If you
don't want fellow students getting in to your laptop while you're gone
for the weekend, the above is fine.

If you're a journalist in a foreign country who needs to leave her
laptop in her hotel room while meeting a source, that's not sufficient.
My recommendation from my original reply would be more fitting.  It
should work with Secure Boot as well.

However, the golden rule still applies.  Physical access trumps all
defensive measures.  The absolute best you can do is detect that
physical access occurred.  From there, you're hoping there are no
hardware implants or other devices outside the scope of software
security.

thx,

Jason.