blob: 6b81c0527f3c517d66eaeef4168eeea3586b0280 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
a
auth0 auth3
"A"*512 (2b) stack smashing detected stack smashing detected
Both failures are because of __stack_chk_fail@plt:
0x000000000040095d <checkpass+215>: e8 8e fd ff ff call 0x4006f0 <__stack_chk_fail@plt>
and:
0x000000000040092c <checkpass+140>: e8 7f fd ff ff call 0x4006b0 <__stack_chk_fail@plt>
Ret.addr (4b) stack smashing detected stack smashing detected
Undoubtedly, this is due to something similar.
b
$ cat /proc/sys/kernel/randomize_va_space
2
So, yes, full randomisation.
It helps, because we cannot find the right address anymore using objdump.
c
Yes, then also the standard library addresses are randomised.
d
$ objdump -p auth0
auth0: file format elf64-x86-64
Program Header:
...
STACK off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**4
filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-
As you can see, it has only rw permissions, not x. This helps, because otherwise we could
overwrite the stack with code, and overwrite the return address with a stack address to
execute our own code.
I don't see any advantage in this though, when stack protection is enabled (because then
it is infeasible to overwrite the return address and pass the checks), but I might be wrong.
|
