See: https://bugzilla.redhat.com/show_bug.cgi?id=1395135 http://openwall.com/lists/oss-security/2016/11/15/1 https://harald.hoyer.xyz/2016/11/15/dracut-and-cve-2016-4484-cryptsetup-initrd-root-shell/ So the main point is that the issue can be mitigated by setting a bootloader password, which makes sense, and our installer allows that, but I don't believe that it adds the "rd.shell=0" to the kernel command line when you do that, so perhaps it should.
Although the actual shell script should also be "fixed", an example patch is available via http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html
CC: (none) => doktor5000, mageia
That patch only applies to Debian. Supposedly dracut has something with a similar bug, but it's not the same code.
thierry, martin, any comment about https://bugzilla.redhat.com/show_bug.cgi?id=1395135#c3 ?
Assignee: thierry.vignaud => mageiatoolsCC: (none) => mageia
In my opinion, this issue is about user education. Forcing the use of rd.shell=0 when encrypting the root file system has implications in recovering from things like a power failure leaving the root file system requiring manual repair. Without testing, I'm not sure if the failure to mount after decrypting would then prevent booting or not. As such, adding the option to add rd.shell=0 when choosing to encrypt the root file system should be considered for a future enhancement. Adding a grub password is a good recommendation, though it should be entirely the admin's choice. Adding a bios/uefi password is beyond the scope of software. It's a good suggestion, where the potential attacker has physical access, though it doesn't prevent them from physically destroying the hard drive. Same with the usually related security suggestion to block booting from removable media. Even though cves have been assigned, I don't consider this to be a security issue, or worthy of being considered as a potential release blocker.
CC: (none) => davidwhodgins
An according to the council meeting, user education can start with errata. Can someone that understands this write an erratum entry for this?
Keywords: (none) => FOR_ERRATA6
Whiteboard: (none) => MGA6TOO, MGA5TOO
Added a Security issues section in errata https://wiki.mageia.org/en/Mageia_6_Errata#Security_issues Boot of system with cyphered partitions - CVE-2016-4484 Failed tries to enter the password of a cyphered partition with LUKS end with a shell. http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html People who want to secure their system have to: add a BIOS password add a grub password add “rd.shell=0” to the kernel command line
CC: (none) => yves.brungard_mageia
Keywords: FOR_ERRATA6 => IN_ERRATA6
Removing MGA5TOO, since this won't be addressed there.
Whiteboard: MGA6TOO, MGA5TOO => MGA6TOO
Status comment: (none) => Should be mitigated by the installerTarget Milestone: --- => Mageia 7
Whiteboard: MGA6TOO => MGA7TOO, MGA6TOO
Whiteboard: MGA7TOO, MGA6TOO => MGA7TOO
CC: (none) => mageia
Target Milestone: Mageia 7 => Mageia 8
to test this CVE: http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html
As for semi-private teachers, companies with more resources have always spent more on their user education starting with the high support level. https://cheapessaywriter.co.uk
CC: (none) => marthawelch1
Why not adding rd.shell=0 to Kernel command line when user wants a GRUB password like Fedora does with Anaconda? Updating SRPM version number. Until this, errata for this from M6 should be also part of Erratas M7 and M8.
CC: (none) => ouaurelienSource RPM: dracut-044-11.mga6.src.rpm => dracut-051-4.mga8.src.rpm
CC: (none) => tmb
Martin, Thomas, what do you think about this one ?
Whiteboard: MGA7TOO => MGA7TOO, MGA8TOO
CC: (none) => dinexat235
Didnt see this until now. Per comment 10 for errata
CC: (none) => friKeywords: (none) => FOR_ERRATA7, FOR_ERRATA8
https://wiki.mageia.org/en/Mageia_7_Errata#Security https://wiki.mageia.org/en/Mageia_8_Errata#Security This bug makes it easy to destroy things, but the encrypted content is still encrypted. So encryption is still good enough for must use cases IMO.
Keywords: FOR_ERRATA7, FOR_ERRATA8 => IN_ERRATA7, IN_ERRATA8
Removing Mageia 7 from whiteboard due to EOL: https://blog.mageia.org/en/2021/06/08/mageia-7-will-reach-end-of-support-on-30th-of-june-the-king-is-dead-long-live-the-king/
Whiteboard: MGA7TOO, MGA8TOO => MGA8TOO
Removing Mageia 8 from whiteboard due to EOL!
CC: (none) => geiger.david68210Target Milestone: Mageia 8 => Mageia 9Whiteboard: MGA8TOO => MGA9TOO
It is since long also in mga9 errata https://wiki.mageia.org/en/Mageia_9_Errata#Security
Target Milestone: Mageia 9 => Mageia 10Keywords: (none) => IN_ERRATA9