From 36bca1d32a34101767c1b9290ccf44c66849b981 Mon Sep 17 00:00:00 2001 From: Ward Wouts Date: Tue, 14 Feb 2023 09:33:01 +0100 Subject: [PATCH] add slide about protections --- index.html | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/index.html b/index.html index 7a8788e..1705065 100644 --- a/index.html +++ b/index.html @@ -152,7 +152,7 @@ C is full of holes, let's get to know one. Old skool, so no OS or hardware protections. Which today is mostly relevant in IoT. (Remember, the `S` in `IoT` stands for Security.) -Stack smashing is making use of a buffer overflow vulnerability in code using variables on the stack. This type of vulenrability has been known for a long time. This attack was first properly documented in Phrack #49. +Stack smashing is making use of a buffer overflow vulnerability in code using variables on the stack. This type of vulnerability has been known for a long time. This attack was first properly documented in Phrack #49. .footnote[Phrack #49(http://www.phrack.org/issues/49/14.html#article)] ] @@ -355,6 +355,23 @@ Binary here: https://wizeazz.nl/smash/code/demo ] --- template: inverse +# Protections +--- +.left-column[ +## Protections +] +.right-column[ +- Stack canaries
+ Place a value before the return address and check if it's been changed before returning from a function. +- Nonexecutable stack
+ W^X (write or execute) won't execute code on the stack (but will still follow return addresses). +- Randomization
+ Change function and stack addresses around so whenever a program is executed the locations are different. + +All these can be worked around given the right conditions. They just make things annoying, euh, harder. +] +--- +template: inverse # DIY --- .left-column[