The canary, __stack_chk_guard, is in the BSS and so will get initialized to zero if it is not explicitly initialized. If the UEFI firmware does not support the RNG protocol, then the canary will not be randomized and will be zero. This seems like a possibly easier value to write by an attacker. Initialize canary to static random bytes, so that it is still random when there is no RNG protocol. Set at least one byte to NUL to protect against string buffer overflow attacks. Code that writes NUL terminated strings will terminate when a NUL is encountered in the input byte stream. So the attacker will not be able to forge the canary by including it in the input stream without terminating the string operation and thus limiting the stack corruption.
[1] https://www.sans.org/blog/stack-canaries-gingerly-sidestepping-the-cage/ Signed-off-by: Glenn Washburn <developm...@efficientek.com> --- grub-core/kern/efi/init.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/grub-core/kern/efi/init.c b/grub-core/kern/efi/init.c index e759cc315b85..08e24d46fad9 100644 --- a/grub-core/kern/efi/init.c +++ b/grub-core/kern/efi/init.c @@ -45,7 +45,8 @@ static grub_guid_t rng_protocol_guid = GRUB_EFI_RNG_PROTOCOL_GUID; */ static grub_efi_uint8_t stack_chk_guard_buf[32]; -grub_addr_t __stack_chk_guard; +/* Initialize canary in case there is no RNG protocol. */ +grub_addr_t __stack_chk_guard = (grub_addr_t) 0x00f2b7e2f193b25c; void __attribute__ ((noreturn)) __stack_chk_fail (void) -- 2.34.1 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel