-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Open
Description
Ventoy is great. But, for some users, it's critical to have security guarantees. Currently, ventoy has some security issues:
- Secure Boot certificate is same for every Ventoy installation, meaning that attacker may use ventoy key to sign their malicious kernels and replace legitimate ones.
- ISOs, configuration files and grub modules can also be easily replaced.
Why should we consider this real threat?
Imagine this threat model:
- attacker writes some kilobytes of zeros to damage your filesystem (works even on encrypted disks)
- attacker replace your kernel with malicious and sign it with ventoy key
- you boot into ventoy to repair your filesystem
- you boot with attacker's kernel and get your passphrase leaked.
Or this one:
- attacker modifies ISO and, if needed, checksum files
- attacker damages your filesystem (as described in 1st model)
- you boot into attacker's ISO, decrypt disk and get your passphrase leaked.
Solutions
-
- generate key individually for each installation, or let user specify directory with SB keys
-
- grub already provides GPG support.
- we generate GPG key, and store it at
/var/lib/ventoy/key.gpg(or at another path) - on installation, we sign all non-executable files at VTOYEFI with GPG
- we generate GPG key, and store it at
- grub support embedding arbitrary (with
memdisk) and configuration files into executable- to prevent an attacker from disabling GPG sign verifying, we embed into grub an archive (search
memdiskin grub documentation) with small config file, which enables GPG verification and loading configs only after verification
- to prevent an attacker from disabling GPG sign verifying, we embed into grub an archive (search
- grub already provides GPG support.
problem: how do we force images/checksums signing, and shall we even forcing it or just throw a warning on boot?
Metadata
Metadata
Assignees
Labels
No labels