Security hole in Cryptsetup - Full HDD encryption? Flash drive sec?

archive.fo/WVg0l

I'm a Holla Forumsilliterate.
Even if it's not legal to have encrypted HDD in my country, I wanted to encrypt some of my HDD (freedom matter), and hide them somewhere, and not touch them anymore.
How is it even possible, if there is exploit like that that pop up from nowhere?
I'm not even talking about the time that takes to clean a big HDD... moving the data and such.

Can anyone, please clarify the situation?

Btw, i'm always afraid of the flash drives. Their could be viruses on them, without even me knowing. I could be infecting everything I touch with them... I'm even afraid to take one in college. Moreover, I don't know how to operate with an air gap computer, since the transferts are made through flash drive.
Also, is there not a problem with HDD/flash drive firmware which would make full encryption useless?

I'm sorry, it's a lot of interrogation, but i'm trapped in my illiteracy.

Real, but blown out of proportion. The given attack scenario (kiosk) overwhelmingly don't use FDE at all.

It doesn't concern FDE of home computer at all (as those typically don't rely on chain of trust to boot).

Cloudshit fails to load your link OP.
THANKS JIMKIKE

This is old news and isn't actually a bug in cryptsetup but in some Debian initramfs script. It seems cryptsetup is one rare example where Debian maintainers are shit. There is also their initramfs-tools cryptroot hook script acting stupid when it comes to handling keyfiles in /etc/crypttab.

Rehosted the .zip archive link just for you:
/ipfs/QmYp77yrcC1yvFVboWybgp1QEPu1YgCfCCSoNo4rKPJqrR

I use FDE, or at least something close, I have it setup like this: /dev/sda (dos label): /dev/sda1 (luks)
This means my grub menu (stage 2 boot) is within the encrypted luks device but grub-install is done on /dev/sda itself (stage 1 boot).
Now here comes the problem: when I boot the first thing I see is a prompt for the passphrase. But if I get my passphrase wrong even once it right away gives me the "grub>" prompt that I don't even know how to reboot or exit from. This can't be the same thing as OP because at this stage I don't even have an access to that buggy initramfs script yet.
Is this a security risk and is there a way to make grub reprompt when I get my passphrase wrong?

...

...

...

...

...

...

ITT:. A duel of egos

[Citation Needed]

Anybody else using FDE+grub? Can you try entering a wrong passphrase on your boot and tell me what happens?

It's not a chain of trust if stage1 isn't verified before executing it somehow. Your setup can be "hacked" by pulling out the HDD, and overwriting stage1 with a backdoor which logs the passphrase.

Chain of trust = your own EFI keys in bios, secure boot enabled. Another example is locked down android bootloader. CHoT simply means that nobody can boot any other sequence than the signed one.

I know the Holla Forums meme is to consider EFI a botnet, but it's normal for people to fear something they don't understand.

Note that the point of FDE is not to provide chain of trust. CHoT merely helps ensure the boot sequence isn't backdoored somehow.

Yeah of course it can be tampered with if someone has my laptop available for more than a few seconds, I'm not retarded. My threat model doesn't include such attacks anyway.
I'm just asking if anybody is seeing this behavior when they enter their passphrase wrong.

Depends what you have in your grub.cfg. The whole luks mount & loading the rest should be enclosed in infinite loop like:

while true; do cryptomount -a; root (...); kernel ...; initrd ...; boot; done

Btw, doing it from grub like this is kinda tardy - makes sense only if you have system disk drive so small you cant afford large, separate /boot to host kernel and initrd. Most people unlock the luks partition from initrd.

But isn't grub.cfg only for the grub menu (stage 2), while grub-install only looks for GRUB_ENABLE_CRYPTODISK=y in /etc/default/grub?
It's simply because I'm lazy and don't want to have a separate boot partition outside of luks and only one system that can install/modify the bootloader, or to have separate boot partitions outside of luks for all systems. Having everything within luks makes things simpler despite initial system installations being slightly more complicated.

it's fucking nothing.
it's nothing more than a DoS/destruction attack and it requires physical access.
If somebody has physical access to your computer, they might as well smash it with a hammer.

in other words:
OP, stop being a dumbass and learn to read.