CVE-2016-4484:A vulnerability in Cryptsetup, concretely in the scripts that unlock the system partition when the partition is ciphered using LUKS (Linux Unified Key Setup). This vulnerability allows to obtain a root initramfs shell on affected systems. [...]
During the installation of Ubuntu, one of the first steps is to prepare the target partition (make partitions if needed, and/or format them). At this stage, the user is asked to "Encrypt the new (LXK)ubuntu installation for security".
This isn't as tragic as it at first sounds, because it does not leave the whole drive unlocked; the root shell is in the pre-boot environment. However, from this shell you have the ability to install backdoors in /boot or trojan the kernel itself.
But seriously, how many more times is Linux going to have a "hold down a key to unlock" bug? I'm almost at the point where I need a tag for this.
OK, I'm torn on this. One half of me is embarrassed that such a stupid shell-script bug exists. On the other hand, dropping into an initrd shell is precisely what I expect should the computer not manage to continue bootup to the actual operating system. So that I can try to fix things (which, I assume, >99% of computer users wouldn't even try). Also the "but in special, locked down environments" argument is bogus. When you have to enter the global "decrypt roots" password on bootup, its probably not a ATM or Infotainment-Kiosk.
To the uninitiated: there is a limited, text-only interface which you get dropped into should your computer fail to boot, and because of an embarrassingly stupid bug this also happens when you enter the wrong bootup-passsord many times. Your computer is still encrypted, and your files cannot be accessed. But an attacker might use this recovery-interface to do mischief.
Well. I think the assumption here is "if I have answered yes to: do not boot if I don't know the password", then, you know, do not boot. Which is not reasonably interpreted as "let someone run arbitrary instructions on my CPU up to and including trojaning my kernel."
Exploiting this only sounds "hard" until someone has pre-rolled the rootkit into an easily-googlable USB stick that presents as a keyboard device.
I completely agree with you.
But most likely making the chain from bootloader to fully running system resilient to attacks was never a priority.
The philosophy of “provide help to tinkerers for repair at every step” is not easily changed to “do not provide any assistance to attackers”.
Time to have some attention deficit teenagers implement a replacement from scratch ;-)
"Linux: It Just Wasn't A Priority"™
Well I do remember being a user of your fine software, and lots of rather interesting security angles weren't a priority there either.
Your carping about shite software is good fun (hey, that's why I keep reading too), but a dash of empathy -- I dunno, as if you had been in the trenches and shipped f'ing buggy releases yourself -- would contribute to the betterment of the race...
Bullshit.
I'm not sure the "Well, _you_ do a better job, then" argument works here.
PS The "Well, _you_ do a better job, then" argument has never worked for anything.
I said empathy, and both of you shortcircuited.
"Let's see you do better" is not empathy.
jwz, you can say bullshit just because the CVE database doesn't go all that far back. But you've written yourself that the NN you worked on was rushed code. It builds, it ships. It's crashed on me over f'g title tags; it's crashed on me over stupid array manipulations in JS.
We all point out at shitty software. But doing so without some hint of acknowledgement of, hey, maybe I also shipped some shite is... [ your word here ].
I think the word you're looking for is:
jwz said
Oh gawd, SystemBoot™ incoming!