Researchers disclose a 55-year-old vulnerability affecting macOS, Windows and Linux. Exploitation is trivial and requires no special tools. No patch exists.
This does however make me wonder if it’s possible to interact with a Linux system without first logging in. Some bootloaders have a shell and I think there’s also a UEFI shell? No idea what they are capable of, though.
Well that is exactly what chroot’ing is, loading up another linux instance so you can modify the local (usually broken) one
This is intentional behavior as you need physical access to the drive, and most sensitive information is either encrypted by your application(keyring, password manager, password protected files, etc), or you can choose to encrypt your whole drive
Not directly. UEFI itself only supports mounting a minimal set of filesystems. That’s why your EFI system partitiion needs to be FAT32, for example, and why the kernel and initial ramdisk are also located there. UEFI mounts the ESP and executes the bootloader, which then loads the kernel (located at ESP/vmlinuz-linux on Arch) and initial ramdisk (ESP/initramfs-linux.img) into memory. The initial ramdisk is a compressed image of an early root filesystem that contains the tools and drivers necessary to boot the full system, including the filesystem drivers for ext4/btrfs/whatever.
You could build an EFI program that natively supports different filesystems, though.
This does however make me wonder if it’s possible to interact with a Linux system without first logging in. Some bootloaders have a shell and I think there’s also a UEFI shell? No idea what they are capable of, though.
Well that is exactly what chroot’ing is, loading up another linux instance so you can modify the local (usually broken) one
This is intentional behavior as you need physical access to the drive, and most sensitive information is either encrypted by your application(keyring, password manager, password protected files, etc), or you can choose to encrypt your whole drive
Not directly. UEFI itself only supports mounting a minimal set of filesystems. That’s why your EFI system partitiion needs to be FAT32, for example, and why the kernel and initial ramdisk are also located there. UEFI mounts the ESP and executes the bootloader, which then loads the kernel (located at
ESP/vmlinuz-linuxon Arch) and initial ramdisk (ESP/initramfs-linux.img) into memory. The initial ramdisk is a compressed image of an early root filesystem that contains the tools and drivers necessary to boot the full system, including the filesystem drivers for ext4/btrfs/whatever.You could build an EFI program that natively supports different filesystems, though.
I mean you can easily edit grub at boot and boot straight into single user mode without logging in.