[dm-crypt] About CVE-2016-4484: - Cryptsetup Initrd root Shell

Sven Eschenberg sven at whgl.uni-frankfurt.de
Wed Nov 16 02:15:30 CET 2016

Am 16.11.2016 um 01:08 schrieb Jonas Meurer:
> Hi list,
> Am 16.11.2016 um 00:52 schrieb Arno Wagner:
>> On Wed, Nov 16, 2016 at 00:28:50 CET, Sven Eschenberg wrote:
>> [...]
>>> The CVE however assumed, that you can not simply access the internal
>>> parts of the machine. Still, more fuzz than substance in that CVE,
>>> if you ask me.
>> My take also. Probably some ego-boosting going on
>> somewhere in this affair. The whole set-up seems
>> contrieved to me and not of general applicability
>> enough to make this a CVE or even a real defect.
>> At best, I see a mild violation of the "Principle of
>> least surprise". Anybody that really needs the
>> "security" the fix provides has far bigger problems.
> I agree that the whole issue is slightly overexaggerated and there's a
> lot of clickbaiting going on in the news about it. [1]
> Still I agree with the reporters that there are special scenarios where
> the discovered flaw can be considered as vulnerability: For setups where
> the attacker has physical access to keyboard but not to the computer and
> both BIOS and bootloader are locked.
> This is a very special setup but I can imagine that it exists at public
> computers like in libraries, universities, bars, ...

If the adversary does not care about angry looks and the like he/she can 
always access more than just the keyboard. Nothing a set of battery 
powered tools can't fix ;-). SCNR.

> While I don't agree on the way this issue was handled and I'm not
> convinced that it deserves a CVE, I agree that we (as the distribution
> developers/maintainers) should fix it in some way.
> At the moment I'm inclined to suggest to propose a change to
> initramfs-tools which disables the dropping to emergency shell per
> default and reboots/freezes instead. Dropping to emergency shell in case
> of an error during initramfs could be activated manually through a boot
> parameter.

I personally would prefer an authenticated root-shell as I said before. 
But that's probably a matter of taste. If parsing of the root parameter 
fails somehow, you'll certainly have a hard time finding out, what is 
going on. A secured root-shell seems a little more robust to me.

> Cheers,
>  jonas
> [1] an extreme example is the headline "Major Linux security hole found
> in Cryptsetup script for LUKS disk encryption", found here:
> http://betanews.com/2016/11/15/linux-security-bug-cryptsetup-luks/

There's a whole bunch of headlines among these lines. I've read that 
cryptsetup has a vulnerability exposing a root-shell on an encrypted 
system. Not quite so.



More information about the dm-crypt mailing list