As described in the security report, CVE-2016-4484, the hole allows attackers "to obtain a root initramfs [initial RAM file system] shell on affected systems. The vulnerability is very reliable because it doesn't depend on specific systems or configurations. Attackers can copy, modify, or destroy the hard disc as well as set up the network to exflitrate data. This vulnerability is specially serious in environments like libraries, ATMs, airport machines, labs, etc, where the whole boot process is protected (password in BIOS and GRUB) and we only have a keyboard or/and a mouse."
Now for the really embarrassing part. Want to know how to activate it? Boot the system and then hold down the enter key. Wait. After about a minute and a half, you'll find yourself in a BusyBox root shell. You now control the horizontal, you now control the vertical, and whoever owns the system is not going to be happy with you.
The root of this root problem is in the /scripts/local-top/cryptroot file. Once you've gone past the maximum number of trials for transient hardware faults, 30 on x86 architectures, you gain root-level access.
This is an example of how open source fails. Just like the OpenSSL Heartbleed security hole, once you look at the code, the problem leaps out at you. But, if you don't look, it just hides there in plain sight. Open-source security only works if you actually read the code.
What's even more annoying, this only works if you've encrypted your system partition. Yes, by doing the smart thing of using encryption, you've actually opened the door to this attack. Fun!
You can't use this to break into users' encrypted partitions. Of course, you can still wreck them.
Now, some of you are saying, "What does this matter! You still need to be at a console to do it and if you're at the machine, you're already three quarters of the way to wrecking any system." True, but I have one word for you: Cloud.
Elevation of privilege: Since the boot partition is typically not encrypted. Then:
It can be used to store an executable file with the bit SetUID enabled, which can later be used to escalate privileges by a local user.
If the boot is not secured, then it would be possible to replace the kernel and the initrd image.
Information disclosure: It is possible to access all the disks. Although the system partition is encrypted it can be copied to an external device, where it can be later be brute forced. Obviously, it is possible to access non-encrypted information in other devices.
Denial of service: The attacker can delete the information on all the disks.
Fortunately, it's easy to fix. Just edit the cryptroot file so that when the number of password guesses has been exhausted, the system stops the boot sequence.
The Linux distributors will soon have this fixed. But, in the meantime, we've got another security headache. Savvy Linux administrators shouldn't wait. They should patch the configuration file.