The memset overflows the four bytes stack variable and modifies the canary value.
The 64bits canary 0x5429851ebaf95800 can't be predicted, but in specific situations is not re-generated and can be bruteforced or in other situations can be leaked from memory for example using a format string vulnerability or an arbitrary read wihout overflowing the stack.
If the canary doesn't match, the libc function __stack_chck_fail is called and terminates the prorgam with a SIGABORT which generates a coredump, in the case of archlinux managed by systemd and are stored on "/var/lib/systemd/coredump/"
❯❯❯ ./test
*** stack smashing detected ***:
fish: './test' terminated by signal SIGABRT (Abort)
[sudo] password for xxxx:
Decoding file core.test.1000.c611b7caa58a4fa3bcf403e6eac95bb0.1121.1574354610000000
core.test.1000.c611b : decoded 249856 bytes
❯❯❯ sudo gdb /home/xxxx/test core.test.1000.c611b7caa58a4fa3bcf403e6eac95bb0.1121.1574354610000000 -q
We specify the binary and the core file as a gdb parameters. We can see only one LWP (light weight process) or linux thread, so in this case is quicker to check. First of all lets see the back trace, because in this case the execution don't terminate in the segfaulted return.
We can see on frame 5 the address were it would had returned to main if it wouldn't aborted.
Happy Idea: we can use this stack canary aborts to detect stack overflows. In Debian with prevous versions it will be exploitable depending on the compilation flags used.
And note that the canary is located as the last variable in the stack so the previous variables can be overwritten without problems.
沒有留言:
張貼留言