Hector Marco

I just looked this up and to save others the time, this was an integer underflow bug in the Grub2 bootloader's password protection[0], not Linux itself. Cool example, though. [0] http://hmarco.org/bugs/CVE-2015-8370-Grub2-authentication-bypass.html#…

"Linux" had a bug in which you could log into a system by pressing backspace 28 times a few years ago. And by Linux, I meant GRUB[1], and in turn, (many) Linux systems. We're comparing Linux and Windows, an operating system that contains 3.5 million files[2] (of course, not just the kernel in this case). That isn't really fair. Code is as perfect as humans can make it, and it certainly does not help that there's so much to take into account. [1] http://hmarco.org/bugs/CVE-2015-8370-Grub2-authentication-bypass.html [2] https://arstechnica.com/gadgets/2018/03/building-windows-4-million-com…

Maybe this[1] one? Hit enter 30 times to get a root initramfs on encrypted, Debian based distros. My laptop was vulnerable to this one for quite a while. [1] http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_s…

See the write up here: http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_s…

http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_s… If you use Debian, Ubuntu, Fedora and have encrypted the system partition you are potentially vunerable. To exploit, reboot server, hold down enter key for 70+ seconds and you'll be dropped into a root shell.

Same team found a similar vulnerability last year in grub: http://hmarco.org/bugs/CVE-2015-8370-Grub2-authentication-bypass.html

CVE-2015-8370: http://hmarco.org/bugs/CVE-2015-8370-Grub2-authentication-bypass.html

On further reading and wondering what some of these terms / tools are: since this is describing a system with un-attended decryption, it seems like it literally requires passwordless access to the disk encryption keys. If that re-reading is correct: yeah, there's not much choice but to put all hope in your code + the TPM, since you essentially can't wait for a password. You get what you pay for in that case - no password means no password, so you're inherently vulnerable to exploits like this. The linked article, https://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_… , seems to describe this kind of setup: the exploit gets you root in the boot partition only, but not any encrypted volumes, so encrypted data is still encrypted. An attacker could get access to anything not protected otherwise though, e.g. unencrypted volumes and hardware, which is a potentially big problem for cloud environments but not so much personal device theft (they already have the hardware).

FYI: If you're comfortable with Gentoo, the jump to Hardened Gentoo[1] is an easy one[2] and gives TrustedBSD[3] a run for its money w/r/t out-of-the-box security. It has the SElinux MAC, role based access controlled stuff from GRsec alternatively [you can mix and match GRsec + SElinux except for RBAC and SElinux's ACL system), grsec's ASLR at runtime, modified versions of musl/uclibc, stack protection support (why anyone would write software that could possibly be EIP exploited with countless ASan damn well integrated into some compilers, I haven't a clue), and a whole host more. Some interesting academic work: http://hmarco.org/data/OnTheEffectivness-NX-SSP-RenewSSP-and-ASLR.pdf While SSP is not enough, (use PIE too): http://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html A fun toy: https://github.com/JhetoX/VectorAttackScanner [1]https://wiki.gentoo.org/wiki/Project:Hardened [2]https://wiki.gentoo.org/wiki/Hardened/Introduction_to_Hardened_Gentoo [3]Granted I haven't used it in ages, it's still the benchmark I use in my mind, back when Linux 2.2 was rife with out-of-the-box ROP vulns.