Assignment 2, 3

1 files changed, 43 insertions, 0 deletions

diff --git a/CamilStaps-s4498062-Assignment-3/ex5 b/CamilStaps-s4498062-Assignment-3/ex5
new file mode 100644
index 0000000..6b81c05
--- /dev/null
+++ b/CamilStaps-s4498062-Assignment-3/ex5
@@ -0,0 +1,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.
+