[Support-team] Cryptsetup Vulnerability Grants Root Shell Access on Some Linux Systems

Daniel Kahn Gillmor dkg at fifthhorseman.net
Wed Nov 16 16:52:16 EST 2016


On Thu 2016-11-17 00:53:47 +0900, Jamie McClelland wrote:

> I also saw this yesterday and started to panic.
>
> But then I read it more closely and realized that it wasn't quite as
> serious as it sounds.
>
> This attack requires either physical access to the machine OR remote
> console access. In addition, you have to be able to reboot the machine.
>
> It's quite hard to get remote console access to our machines (you need
> an ssh key). And, you would have to compromise two accounts on our
> console server to get remote access to a machine and remote access to
> our power device to restart a machine. 
>
> If you have physical access to the machine, you still have to restart
> the server (which would trigger a nagios alert) and you would be
> captured on our camera system.
>
> Then, you would have access to a our /boot partition (which is the only
> partition that is un-encrypted). Furthermore - if you have physical
> access to the machine, it would be far simpler to remove the disks in
> order to access the unencrypted /boot partition rather than go through
> the trouble of getting cryptsetup to drop you to a shell.
>
> I think the bottom line for us is: if a server is rebooted without our
> knowledge, we should not enter a passphrase and start it but instead
> treat the /boot partition with suspicion.

I agree with Jamie on this analysis.  This CVE report was confusingly
mis-represented initially, and its authors have walked it back quite a
bit.

I'd love to review and harden MF/PL's boot processes in such a way that
we could be confident that the reported bug in the initramfs scripts for
cryptsetup was actually a degradation of security, but that's simply not
the case today.

If anyone wants to have a discussion about steps we could take in that
direction, i'm all ears.  But an attacker with console access and
physical access already has quite a bit of potential control over the
machine.  That's why we limit console access and physical access :)

          --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 962 bytes
Desc: not available
URL: <http://lists.mayfirst.org/pipermail/support-team/attachments/20161117/93ff4dec/attachment.sig>


More information about the Support-team mailing list