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

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

[Milan Broz]

Hi all,

just little bit clarification about CVE-2016-4484
http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html

This bug is *NOT* cryptsetup/LUKS upstream bug, it is a minor problem in scripts
unlocking an encrypted system.

It allows attacker to drop to initramdisk shell (without decryption of LUKS data).

The scripts are part of Debian cryptsetup package (as an addition to upstream)
or part of dracut package (if dracut is used).

(The info about the problem was embargoed until the talk and only Debian maintainers
were informed in advance.)

Milan

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

[Arno Wagner]

Interesting. Does not very seem relevant, except in special
situations, where an attacker can boot the system and can
access the console, but cannot change the boot-process 
or boot image itself.

This would immediately exclude any normal PC
from consideration, because there, if you can boot,
you can also boot something else which gives you the
same capabilities (or better) than this exploit.
If you can get BIOS access, the same might be possible, 
so servers with ILO should also not be affected.

My take would be that of this vulnerabilituy allowas
an attack, then the security model used is broken in 
the first place. Of course, there are environments that
need two (or more) effective security mechanisms, so 
fixing this is a good idea, but (almost) nobody needs
to be very concerned about it.

Regards,
Arno


On Tue, Nov 15, 2016 at 13:34:49 CET, Milan Broz wrote:
> Hi all,
> 
> just little bit clarification about CVE-2016-4484
> http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html
> 
> This bug is *NOT* cryptsetup/LUKS upstream bug, it is a minor problem in scripts
> unlocking an encrypted system.
> 
> It allows attacker to drop to initramdisk shell (without decryption of LUKS data).
> 
> The scripts are part of Debian cryptsetup package (as an addition to upstream)
> or part of dracut package (if dracut is used).
> 
> (The info about the problem was embargoed until the talk and only Debian maintainers
> were informed in advance.)
> 
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

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

[Sven Eschenberg]

Obviously it is not a bug in cryptsetup, but rather in dracut and some 
distributions initrd scripts. What's really annoying about the CVE is 
the fact, that it is mostly irrelevant. If I can get to the password 
entry of an initrd, I obviously have control over the boot process. If I 
do have control over the boot process I have a splendid variety of 
options to do all the things described in the CVE.

I wonder why the authors of the CVE recommend to freeze the system, 
instead of adding auth to get a shell. Seems quite stupid to completely 
remove the ability to investigate problems.

-Sven

Am 15.11.2016 um 13:34 schrieb Milan Broz:
> Hi all,
>
> just little bit clarification about CVE-2016-4484
> http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html
>
> This bug is *NOT* cryptsetup/LUKS upstream bug, it is a minor problem in scripts
> unlocking an encrypted system.
>
> It allows attacker to drop to initramdisk shell (without decryption of LUKS data).
>
> The scripts are part of Debian cryptsetup package (as an addition to upstream)
> or part of dracut package (if dracut is used).
>
> (The info about the problem was embargoed until the talk and only Debian maintainers
> were informed in advance.)
>
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

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

[Robert Nichols]

On 11/15/2016 07:32 AM, Sven Eschenberg wrote:
> Obviously it is not a bug in cryptsetup, but rather in dracut and some
> distributions initrd scripts. What's really annoying about the CVE is
> the fact, that it is mostly irrelevant. If I can get to the password
> entry of an initrd, I obviously have control over the boot process. If I
> do have control over the boot process I have a splendid variety of
> options to do all the things described in the CVE.
>
> I wonder why the authors of the CVE recommend to freeze the system,
> instead of adding auth to get a shell. Seems quite stupid to completely
> remove the ability to investigate problems.

The boot process can be configured to deny that control (BIOS configured 
to boot from the internal drive only, GRUB set up to require a password 
for all except the default selection).

On a Red Hat system with an encrypted root filesystem, I get 5 attempts 
to enter the encryption password. Then the system locks up, and the only 
options are to (a) press <ESC> to dismiss the graphical boot screen and 
see a "wrong password" message, and/or (b) press CTRL-ALT-DEL to reboot.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

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

[Sven Eschenberg]

Am 15.11.2016 um 16:18 schrieb Robert Nichols:
> On 11/15/2016 07:32 AM, Sven Eschenberg wrote:
>> Obviously it is not a bug in cryptsetup, but rather in dracut and some
>> distributions initrd scripts. What's really annoying about the CVE is
>> the fact, that it is mostly irrelevant. If I can get to the password
>> entry of an initrd, I obviously have control over the boot process. If I
>> do have control over the boot process I have a splendid variety of
>> options to do all the things described in the CVE.
>>
>> I wonder why the authors of the CVE recommend to freeze the system,
>> instead of adding auth to get a shell. Seems quite stupid to completely
>> remove the ability to investigate problems.
>
> The boot process can be configured to deny that control (BIOS configured
> to boot from the internal drive only, GRUB set up to require a password
> for all except the default selection).

Interesting, haven't seen any such firmware so far for PC. A firmware 
that indeed can disable the bootmenu etc. whilst not requiring a 
password during boot would be the one exception of course.
Most firmwares will actually happily boot the configured port, even when 
the device is switched over, with one exception: Secure Boot with a 
uniquely signed bootloader and a unique key installed in the firmware. 
(Requires a non vendor key).
>
> On a Red Hat system with an encrypted root filesystem, I get 5 attempts
> to enter the encryption password. Then the system locks up, and the only
> options are to (a) press <ESC> to dismiss the graphical boot screen and
> see a "wrong password" message, and/or (b) press CTRL-ALT-DEL to reboot.
>

I'm still considering this a stupid approach, I prefer a sulogin with 
auth approach and happily live with it.

-Sven

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

[Robert Nichols]

On 11/15/2016 12:40 PM, Sven Eschenberg wrote:
>
>
> Am 15.11.2016 um 16:18 schrieb Robert Nichols:
>> On 11/15/2016 07:32 AM, Sven Eschenberg wrote:
>>> Obviously it is not a bug in cryptsetup, but rather in dracut and some
>>> distributions initrd scripts. What's really annoying about the CVE is
>>> the fact, that it is mostly irrelevant. If I can get to the password
>>> entry of an initrd, I obviously have control over the boot process. If I
>>> do have control over the boot process I have a splendid variety of
>>> options to do all the things described in the CVE.
>>>
>>> I wonder why the authors of the CVE recommend to freeze the system,
>>> instead of adding auth to get a shell. Seems quite stupid to completely
>>> remove the ability to investigate problems.
>>
>> The boot process can be configured to deny that control (BIOS configured
>> to boot from the internal drive only, GRUB set up to require a password
>> for all except the default selection).
>
> Interesting, haven't seen any such firmware so far for PC. A firmware
> that indeed can disable the bootmenu etc. whilst not requiring a
> password during boot would be the one exception of course.
> Most firmwares will actually happily boot the configured port, even when
> the device is switched over, with one exception: Secure Boot with a
> uniquely signed bootloader and a unique key installed in the firmware.
> (Requires a non vendor key).

The machines I have all either (a) if a BIOS administrator password is 
set, requires that password in order to enter the boot menu, or (b) 
allow all alternative devices to be excluded as boot device candidates. 
Either way, you need the BIOS administrator password to get to an 
alternative boot device.

>> On a Red Hat system with an encrypted root filesystem, I get 5 attempts
>> to enter the encryption password. Then the system locks up, and the only
>> options are to (a) press <ESC> to dismiss the graphical boot screen and
>> see a "wrong password" message, and/or (b) press CTRL-ALT-DEL to reboot.
>>
>
> I'm still considering this a stupid approach, I prefer a sulogin with
> auth approach and happily live with it.

sulogin is going to be hard to do if the root filesystem (where 
/etc/shadow resides) has not been decrypted. You would have to have some 
alternative password mechanism, and you can already accomplish that in 
GRUB with password-protected alternatives.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

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

[Sven Eschenberg]

Am 15.11.2016 um 20:19 schrieb Robert Nichols:
> On 11/15/2016 12:40 PM, Sven Eschenberg wrote:
>>
>>
>> Am 15.11.2016 um 16:18 schrieb Robert Nichols:
>>> On 11/15/2016 07:32 AM, Sven Eschenberg wrote:
>>>> Obviously it is not a bug in cryptsetup, but rather in dracut and some
>>>> distributions initrd scripts. What's really annoying about the CVE is
>>>> the fact, that it is mostly irrelevant. If I can get to the password
>>>> entry of an initrd, I obviously have control over the boot process.
>>>> If I
>>>> do have control over the boot process I have a splendid variety of
>>>> options to do all the things described in the CVE.
>>>>
>>>> I wonder why the authors of the CVE recommend to freeze the system,
>>>> instead of adding auth to get a shell. Seems quite stupid to completely
>>>> remove the ability to investigate problems.
>>>
>>> The boot process can be configured to deny that control (BIOS configured
>>> to boot from the internal drive only, GRUB set up to require a password
>>> for all except the default selection).
>>
>> Interesting, haven't seen any such firmware so far for PC. A firmware
>> that indeed can disable the bootmenu etc. whilst not requiring a
>> password during boot would be the one exception of course.
>> Most firmwares will actually happily boot the configured port, even when
>> the device is switched over, with one exception: Secure Boot with a
>> uniquely signed bootloader and a unique key installed in the firmware.
>> (Requires a non vendor key).
>
> The machines I have all either (a) if a BIOS administrator password is
> set, requires that password in order to enter the boot menu, or (b)
> allow all alternative devices to be excluded as boot device candidates.
> Either way, you need the BIOS administrator password to get to an
> alternative boot device.
>

Surprisingly this seems to be the case for the machine I just tested. 
I'd assume an extra option+PW for the boot menu however, since it is not 
a direct access to the setup nor a persistent change. So, yes, admitted, 
with an admin PW one can get all the way to the initram without entering 
an extra password. I wonder however how securely that password is stored?

>>> On a Red Hat system with an encrypted root filesystem, I get 5 attempts
>>> to enter the encryption password. Then the system locks up, and the only
>>> options are to (a) press <ESC> to dismiss the graphical boot screen and
>>> see a "wrong password" message, and/or (b) press CTRL-ALT-DEL to reboot.
>>>
>>
>> I'm still considering this a stupid approach, I prefer a sulogin with
>> auth approach and happily live with it.
>
> sulogin is going to be hard to do if the root filesystem (where
> /etc/shadow resides) has not been decrypted. You would have to have some
> alternative password mechanism, and you can already accomplish that in
> GRUB with password-protected alternatives.
>

No, the root filesystem is the initram (initrd) until rootfs is switched 
over - all you have to do is adding a passwd(file) with an entry to it. 
You won't need shadow anyway, since the only login supported is a root 
login, which implies full access to shadow (usually). Of course you 
would probably not want to just grep the root line from the system, but 
generate a single line passwd(file) with an entry for root with some 
seperate password. If you trust on the cryptographic strength of the 
hashing and salting in the passwd/shadow files, you could include them 
aswell and support user and root logins with sulogin (during initrd). 
Using shadow in this particular case makes sense again.

-Sven

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

[Robert Nichols]

On 11/15/2016 01:42 PM, Sven Eschenberg wrote:
>
>
> Am 15.11.2016 um 20:19 schrieb Robert Nichols:
>> sulogin is going to be hard to do if the root filesystem (where
>> /etc/shadow resides) has not been decrypted. You would have to have some
>> alternative password mechanism, and you can already accomplish that in
>> GRUB with password-protected alternatives.
>>
>
> No, the root filesystem is the initram (initrd) until rootfs is switched
> over - all you have to do is adding a passwd(file) with an entry to it.
> You won't need shadow anyway, since the only login supported is a root
> login, which implies full access to shadow (usually). Of course you
> would probably not want to just grep the root line from the system, but
> generate a single line passwd(file) with an entry for root with some
> seperate password. If you trust on the cryptographic strength of the
> hashing and salting in the passwd/shadow files, you could include them
> aswell and support user and root logins with sulogin (during initrd).
> Using shadow in this particular case makes sense again.

As I said, "some alternative password mechanism."

FWIW in Red Hat systems, at least, there are several values you can pass 
for "rdbreak=" in the boot parameters that will cause the initrd script 
to drop into a debug shell before the decryption password is ever 
requested. It is a long-standing truism that without physical security, 
there is no protection for unencrypted storage on the system.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

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

[Michael Kjörling]

On 15 Nov 2016 20:42 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg):
>> Either way, you need the BIOS administrator password to get to an
>> alternative boot device.
> 
> I wonder however how securely that password is stored?

Almost certainly not securely at all. It certainly is easy to clear
once you have physical access: All you need to do is get access to the
motherboard and either remove/disconnect the CMOS battery, or set a
jumper to a "CLEAR CMOS" or similarly labeled position. I would expect
some modicum of protection such that the password isn't stored in
clear text in NVRAM or flash readable to all and sundry, but I
wouldn't expect anything much more sophisticated than an XOR with a
fixed value, a CRC-32 checksum, or similar. The exact details almost
certainly vary with BIOS implementations and there's no guarantee that
there aren't implementations out there that actually do the right
thing, but BIOS password storage methods is hardly a distinguishing
feature among motherboard manufacturers. Don't expect a proper PBKDF.

Think of the BIOS passwords (both user and administrator) not really
as tamper-proofing measures as much as a tamper-evidence measures.

Feel free to mentally s/BIOS/UEFI/g above if that's your
open-at-the-top-container of hot-breakfast-beverage-of-choice.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

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

[Sven Eschenberg]

Am 16.11.2016 um 00:15 schrieb Michael Kjörling:
> On 15 Nov 2016 20:42 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg):
>>> Either way, you need the BIOS administrator password to get to an
>>> alternative boot device.
>>
>> I wonder however how securely that password is stored?
>
> Almost certainly not securely at all. It certainly is easy to clear
> once you have physical access: All you need to do is get access to the
> motherboard and either remove/disconnect the CMOS battery, or set a
> jumper to a "CLEAR CMOS" or similarly labeled position. I would expect
> some modicum of protection such that the password isn't stored in
> clear text in NVRAM or flash readable to all and sundry, but I
> wouldn't expect anything much more sophisticated than an XOR with a
> fixed value, a CRC-32 checksum, or similar. The exact details almost
> certainly vary with BIOS implementations and there's no guarantee that
> there aren't implementations out there that actually do the right
> thing, but BIOS password storage methods is hardly a distinguishing
> feature among motherboard manufacturers. Don't expect a proper PBKDF.
>
> Think of the BIOS passwords (both user and administrator) not really
> as tamper-proofing measures as much as a tamper-evidence measures.
>
> Feel free to mentally s/BIOS/UEFI/g above if that's your
> open-at-the-top-container of hot-breakfast-beverage-of-choice.
>

That was more of a rhetoric question, to be honest. I have substantial 
doubts that passwords in the very space limited NVRAM are somehow 
cryptographically hashed or something. If you can recover the PW from 
the stored data however, then even tamper-evidence is effectively gone. 
isn't it?

And, let's call it firmware, that should cover for both, UEFI and 
classic BIOS, I think ;-).

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.

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

[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. 

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

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

[Jonas Meurer]

[-- Attachment #1.1: Type: text/plain, Size: 1911 bytes --]

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, ...

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.

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/



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Sven Eschenberg]

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.

Reagards

-Sven

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

[Milan Broz]

On 11/16/2016 02:15 AM, Sven Eschenberg wrote:
...
> 
> 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.

Yes, this is the real "contribution" of reporting a bug with
(possibly even unrelated) project name in headlines.

But seems users themselves correct some stupid article comments,
thanks for it! ;-)

Sometimes I wish security is less theater and more responsibility...
(This bug cost me hours of explanation that upstream has nothing to fix
and that in fact the cryptsetup/LUKS worked as designed.)

Milan

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

[Arno Wagner]

On Wed, Nov 16, 2016 at 08:32:12 CET, Milan Broz wrote:
> On 11/16/2016 02:15 AM, Sven Eschenberg wrote:
> ...
> > 
> > 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.
> 
> Yes, this is the real "contribution" of reporting a bug with
> (possibly even unrelated) project name in headlines.
> 
> But seems users themselves correct some stupid article comments,
> thanks for it! ;-)
> 
> Sometimes I wish security is less theater and more responsibility...
> (This bug cost me hours of explanation that upstream has nothing to fix
> and that in fact the cryptsetup/LUKS worked as designed.)

Tell me about it. I have these discussions regularly as a 
security consultant, simply because a lack of understanding
on customer side and attribution of errors by keyword-matching
instead. 

I think I will add a new section to the FAQ dealing with initrd
issues. 
Contens: 
1) No, the initrd is _not_ part of cryptsetup, it is your
   distro that screwed up if it is broken or insecure.
2) If you depend on the initrd doing something seucrely,
   roll your own and lock that down.
3) (Maybe an example...)

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

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

[David Niklas]

On Wed, 16 Nov 2016 14:48:27
Arno Wagner <arno@wagner.name> wrote:
> On Wed, Nov 16, 2016 at 08:32:12 CET, Milan Broz wrote:
> > On 11/16/2016 02:15 AM, Sven Eschenberg wrote:
> > ...  
> > > 
> > > 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.  
> > 
> > Yes, this is the real "contribution" of reporting a bug with
> > (possibly even unrelated) project name in headlines.
> > 
> > But seems users themselves correct some stupid article comments,
> > thanks for it! ;-)
> > 
> > Sometimes I wish security is less theater and more responsibility...
> > (This bug cost me hours of explanation that upstream has nothing to
> > fix and that in fact the cryptsetup/LUKS worked as designed.)  
> 
> Tell me about it. I have these discussions regularly as a 
> security consultant, simply because a lack of understanding
> on customer side and attribution of errors by keyword-matching
> instead. 
> 
> I think I will add a new section to the FAQ dealing with initrd
> issues. 
> Contens: 
> 1) No, the initrd is _not_ part of cryptsetup, it is your
>    distro that screwed up if it is broken or insecure.
> 2) If you depend on the initrd doing something seucrely,
>    roll your own and lock that down.
> 3) (Maybe an example...)
> 
> Regards,
> Arno
> 

Personally, I've know about this for years (because I could not
remember my password one day), and I thought it was helpful to be able to
drop to a shell when cryptsetup does not return 0.
Great debugging aide if you wrote something wrong in the intrid.

Besides, if I was truly an evil attacker with physical access, surly I
could come up with a better attack then this one (Change out the
cpu/CMOS/BIOS with an evil one! No more TPE! No more Intel TxT! No more
*secure* hardware crypto devices! Etc.!!!).

Sincerely,
David

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

[Jonas Meurer]

[-- Attachment #1.1: Type: text/plain, Size: 823 bytes --]

Hi there,

Am 15.11.2016 um 13:34 schrieb Milan Broz:
> just little bit clarification about CVE-2016-4484
> http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html
> 
> This bug is *NOT* cryptsetup/LUKS upstream bug, it is a minor problem in scripts
> unlocking an encrypted system.
> 
> It allows attacker to drop to initramdisk shell (without decryption of LUKS data).
> 
> The scripts are part of Debian cryptsetup package (as an addition to upstream)
> or part of dracut package (if dracut is used).

I decided to write down my thoughts on CVE-2016-4484 and published them
in a blog post:

https://blog.freesources.org/posts/2016/12/CVE-2016-4484/

Feel free to share your comments, criticism, opinion either in the blog
comments or here on the list.

Cheers,
 jonas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 866 bytes --]

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

[Arno Wagner]

Hi Jonas,

one thing I find particularly telling is that CVE-2016-4484
is still unpublished and there is only a placeholder:

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4484

This rather strongly indicates to me that this was all about
publicity and not about security at all. If they cannot
even be bothered to have that CVE actually out some 20 days
after making a splash at a conference and hyping it to the 
press, this cannot be of any importance, security-wise...

Regards,
Arno




On Wed, Dec 07, 2016 at 12:37:04 CET, Jonas Meurer wrote:
> Hi there,
> 
> Am 15.11.2016 um 13:34 schrieb Milan Broz:
> > just little bit clarification about CVE-2016-4484
> > http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html
> > 
> > This bug is *NOT* cryptsetup/LUKS upstream bug, it is a minor problem in scripts
> > unlocking an encrypted system.
> > 
> > It allows attacker to drop to initramdisk shell (without decryption of LUKS data).
> > 
> > The scripts are part of Debian cryptsetup package (as an addition to upstream)
> > or part of dracut package (if dracut is used).
> 
> I decided to write down my thoughts on CVE-2016-4484 and published them
> in a blog post:
> 
> https://blog.freesources.org/posts/2016/12/CVE-2016-4484/
> 
> Feel free to share your comments, criticism, opinion either in the blog
> comments or here on the list.
> 
> Cheers,
>  jonas
> 
> 




> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier